draft-ietf-geopriv-pdif-lo-profile-00.txt   draft-ietf-geopriv-pdif-lo-profile-01.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Expires: January 3, 2006 Nortel Expires: January 19, 2006 Nortel
H. Tschofenig H. Tschofenig
Siemens Siemens
July 2, 2005 July 18, 2005
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-00.txt draft-ietf-geopriv-pdif-lo-profile-01.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 January 3, 2006. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The GeoPriv PIDF-LO specification provides a flexible and versatile The Presence Information Data Format Location Object (PIDF-LO)
means to represent location information. There are, however, specification provides a flexible and versatile means to represent
circumstances that arise when information needs to be constrained in location information. There are, however, circumstances that arise
how it is represented so that the number of options that need to be when information needs to be constrained in how it is represented so
implemented in order to make use of it are reduced. There is growing that the number of options that need to be implemented in order to
interest in being able to use location information contained in a make use of it are reduced. There is growing interest in being able
PIDF-LO for message and call routing applications. For such to use location information contained in a PIDF-LO for routing
applications to interoperate successfully location information will applications. To allow successfully interoperability between
need to be normative and more constrained than is currently described applications, location information needs to be normative and more
in the PIDF-LO specification. This paper makes recommendations on tightly constrained than is currently specified in the PIDF-LO. This
how to constrain, represent and interpret locations in a PIDF-LO. It document makes recommendations on how to constrain, represent and
further looks at existing communications standards that make use of interpret locations in a PIDF-LO. It further looks at existing
geodetic information for routing purposes and recommends a subset of communications standards that make use of geodetic information for
GML that MUST be implemented by applications to allow message routing routing purposes and recommends a subset of GML that MUST be
to occur. implemented by applications to allow location dependent routing to
occur.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Using Location Information . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Single Civic Location Information . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Civic and Geospatial Location Information . . . . . . . . 7 4. Using Location Information . . . . . . . . . . . . . . . . . 7
3.3 Manual/Automatic Configuration of Location Information . . 8 4.1 Single Civic Location Information . . . . . . . . . . . . 8
4. Geodetic Coordinate Representation . . . . . . . . . . . . . 10 4.2 Civic and Geospatial Location Information . . . . . . . . 9
5. Uncertainty in Location Representation . . . . . . . . . . . 12 4.3 Manual/Automatic Configuration of Location Information . . 11
5.1 Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Geodetic Coordinate Representation . . . . . . . . . . . . . 12
5.2 Ellipsoid Point With Uncertainty Circle . . . . . . . . . 16 6. Uncertainty in Location Representation . . . . . . . . . . . 14
5.3 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . 21 6.2 Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18
6.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 21 6.3 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 21 7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . 23
6.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 22 7.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 23
6.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 22 7.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 23
6.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 24
6.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 23 7.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 24
6.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 23 7.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 24
6.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 23 7.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 25
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . 24 7.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . 25 7.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . 28
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30
12.1 Normative references . . . . . . . . . . . . . . . . . . 29 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31
12.2 Informative References . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 13.1 Normative references . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 31 13.2 Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
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
Intellectual Property and Copyright Statements . . . . . . . 41
1. Introduction 1. CHANGES SINCE LAST TIME
PIDF-LO [1] which was developed by the GEOPRIV working group, is the 1.1 01 changes
IETF recommended way encoding location information and privacy
policies. Location information in PIDF-LO may be described in a
geospatial manner based on a subset of GMLv3, or as civic location
information. PIDF-LO may be used in a variety of ways. For example,
[3] motivates the usage of PIDF-LO in presence based systems.
Further usages are envisioned in the context of emergency services
and other location based routing applications. This document details
the usage of GMLv3 in PIDF-LO by incorporating implementation
experience. Recommendations for formats and conventions are provided
where interoperability might be problematic. For the sake of
compatibility, ease of use and removal of inherent ambiguity apparent
in GML the functionality of other geospatial systems, such as the
3GPP MLP standard [4], are examined.
2. Terminology minor changes to the abstract.
Minor changes to the introduction.
Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [3].
Rectified examples to use position and pos rather than location and
point.
Corrected example 3 so that it does not violate SIP rules.
Added addition geopriv elements to the status component of the figure
in "Using Location Information" to more accurately reflect the
cardinality issues.
Revised text in section "Geodection Coordinate Representation.
Removed last example as this was addressed with the change to
position and pos in previous examples.
2. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [1] is
the IETF recommended way of encoding location information and
associated privacy policies. Location information in PIDF-LO may 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
context of numerous location based applications. This document makes
recommendations for formats and conventions to make interoperability
less problematic. To enhance clarify formats comparisons between GML
and the 3GPP Mobile Location Protocol (MLP) standard [4], are
examined.
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 [2].
3. 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.
Graphically, the structure of the PIDF/PIDF-LO can be depicted as Graphically, the structure of the PIDF/PIDF-LO can be depicted as
follows: follows:
PIDF document PIDF document
tuple 1 tuple 1
status status
geopriv geopriv
location-info location-info
civicAddress civicAddress
location location
usage-rules usage-rules
geopriv 2
geopriv 3
.
.
.
tuple 2 tuple 2
tuple 3 tuple 3
All of these potential sources and storage places for location lead All of these potential sources and storage places for location lead
to confusion for the generators, conveyors and users of location to confusion for the generators, conveyors and users of location
information. Practical experience within the United States National information. Practical experience within the United States National
Emergency Number Association (NENA) in trying to solve these Emergency Number Association (NENA) in trying to solve these
ambiguities led 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 tuple MUST completely define a specific location.
skipping to change at page 6, line 35 skipping to change at page 8, line 42
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.
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 useful of these rules.
3.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
WiFi hotspot, Jane obtains a complete civic address for her current the coffee-shop's WiFi hotspot, Jane obtains a complete civic address
location, for example using [5]. She constructs a Location Object for her current location, for example using [5]. She constructs a
which consists of a single PIDF document, with a single geopriv Location Object which consists of a single PIDF document, with a
tuple, with a single location residing in the <location-info> single geopriv tuple, with a single location residing in the
element. This is largely unambiguous, and if this location is sent <location-info> element. This is largely unambiguous, and if this
over the network, providing it understands civic addresses, correct location is sent over the network, providing it understands civic
handling of any request should be possible. addresses, correct handling of any request should be possible.
3.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 [6]. In this case the location is a geodetic over DHCP as defined in [3]. 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:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
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:civilAddress>
<cl:country>US</cl:country>
<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:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
<tuple id="sg89ae"> <tuple id="sg89ae">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:position>
<gml:Point gml:id="point1" srsName="epsg:4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> <gml:pos>37.775 -122.4194</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:position>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <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>
So the resulting PIDF document contains two geopriv elements each in
a separate PIDF tuple element, the first being a civic address made The constructed PIDF document contains two geopriv elements each in a
up of only country and floor, the second containing the received separate PIDF tuple, the first being a civic address made up of only
geodetic information. If the location is required for emergency floor, the second containing the provided geodetic information. If
routing purposes, which information does a SIP proxy use? Applying the location is required for routing purposes, which information is
rule #8, we will likely fail, or at a minimum need to fall back to used? Applying rule #8, we will likely fail, or at a minimum need to
the second tuple describing the geodetic location, a routing by the fall back to the second tuple describing the geodetic location, a
second floor somewhere in the US is not particularly descriptive. If route described by floor only is precise enough in the normal case to
rule #6 and #7 are applied, then the PIDF-LO document would look permit route selection. If rule #6 and #7 are applied, then the
like: revised PIDF-LO document would look 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:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
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:location> <gml:position>
<gml:Point gml:id="point1" srsName="epsg:4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> <gml:pos>37.775 -122.4194</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:position>
<cl:civilAddress> <cl:civilAddress>
<cl:country>US</cl:country>
<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: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 a geodetic location
at latitude 37:46:30 North and longitude 122:25:10 West. Further at latitude 37.775 and longitude -122.4194. Further that the user is
that the user is on the second floor of the building located at those on the second floor of the building located at those coordinates.
coordinates.
3.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 Erin has a predefined civic location stored in her laptop, since she
normally lives in Sydney, the address in her address is for her 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. Erin decides to visit sunny San Francisco,
and when she gets there she plugs in her laptop and makes a call. and when she gets there she plugs in her laptop and makes a call.
The location sent to the local proxy is her Sydney address, her local Erin's laptop receives a new location from the visited network in San
outbound SIP proxy inserts a new PIDF document asserting her new Francisco and adds this to her existing PIDF location document.
location (or returns an error message with the current location Applying rule #9, the resulting order of location information in the
information). Using rule #9, the resulting PIDF order should be San PIDF document should be San Francisco first, followed by Sydney.
Francisco document first, followed by Sydney document. If the San Since the information is provided by different sources, rule #8
Francisco proxy were to add the location to Erin's existing PIDF should also be applied and the information places in different tuples
document, then the San Francisco tuple SHOULD be placed ahead of the with San Francisco first.
Sydney tuple following rule #8.
4. Geodetic Coordinate Representation 5. Geodetic Coordinate Representation
The geodetic examples provided previously were all based around the The geodetic examples provided in [1] are illustrated using the gml:
gml:location element which uses the gml:coordinates elements (inside location element which uses the gml:coordinates elements (inside the
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. An
alternative is to use the gml:position and gml:pos elements. These alternative is to use the gml:position and gml:pos elements. These
elements have a structured format, in that each field is represented elements have a structured format, in that each field is represented
as a double, and a single space exists between each field. Such a as a double, and a single space exists between each field. Such a
format does not introduce the same degree of misinterpretation. A format does not introduce the same degree of misinterpretation. The
suggested representation therefore for expressing geodetic recommended representation therefore for expressing geodetic
coordinates for emergency call routing would be: coordinates for location based routing applications would be:
<gml:position> <gml:position>
<gml:Point gml:id="point1" srsName="urn:EPSG:geographicCRS:4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>37.775 -122.422</gml:pos> <gml:pos>37.775 -122.422</gml:pos>
</gml:Point> </gml:Point>
</gml:position> </gml:position>
The coordinate reference system (CRS) indicates which numbers in the The coordinate reference system (CRS) indicates which numbers in the
sequence equate to latitude, longitude etc, and in addition to this sequence equate to latitude, longitude etc, and in addition to this
the CRS also provides an indication of direction represented by the the CRS also provides an indication of direction represented by the
sign of the number. For example, in WGS-84 (represented as CRS: sign of the number. For example, in WGS-84 (represented as CRS:
4326), as shown in the code snippet above, the format is latitude 4326), as shown in the code snippet above, the format is latitude
followed by longitude. A positive value for latitude represents a followed by longitude. A positive value for latitude represents a
location north of the equator while a negative value represents a location north of the equator while a negative value represents a
location south of the equator. Similarly for longitude, a positive location south of the equator. Similarly for longitude, a positive
value represents a location east of Greenwich, while a negative value value represents a location east of Greenwich, while a negative value
represents a location west of Greenwich. represents a location west of Greenwich.
EPSG 4326 is the two dimensional WGS-84 representation, if we wanted EPSG 4326 is the two dimensional WGS-84 representation, if we wanted
to represented this in three dimensions, that is with an altitude as 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: well, then we would use EPSG 4979 and the format would be as follows:
<gml:position> <gml:position>
<gml:Point gml:id="point1" srsName="urn:EPSG:geographicCRS:4979"> <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4979">
<gml:pos>37.775 -122.422 22</gml:pos> <gml:pos>37.775 -122.422 22</gml:pos>
</gml:Point> </gml:Point>
</gml:position> </gml:position>
The format using CRS:4979 is similar to CRS:4326, though we now have The format using CRS:4979 is similar to CRS:4326, though we now have
an altitude value. Specifically the altitude is provided in metres an altitude value. Specifically the altitude is provided in metres
above the geoid, which will not be useful for general routing above the geoid, which will not be useful for general routing
applications since the geoid is generally neither ground-level nor applications since the geoid is generally neither ground-level nor
sea-level. However, for more specialized geographic applications it sea-level. However, for more specialized geographic applications it
may be useful. may be useful.
Revisiting the final version of Section 3.2, but using gml:position 6. Uncertainty in Location Representation
and gml:pos, has the following structure:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:mike@seattle.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:pos>37.775 -122.422</gml:pos>
</gml:Point>
</gml:position>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5. Uncertainty in Location 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 today use the point as an absolute value and ignore the
skipping to change at page 12, line 50 skipping to change at page 14, line 50
impossible using base GML. However, only a subset of GML, namely impossible using base GML. However, only a subset of GML, namely
feature.xsd, is mandatory for a PIDF-LO implementation. Extending feature.xsd, is mandatory for a PIDF-LO implementation. Extending
GML to easily represent these shapes may lead to interoperability GML to easily represent these shapes may lead to interoperability
issues and so is not recommended. The authors of this document were 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 unable to find a means to express either an ellipse or and ellipsoid
using only the elements defined in feature.xsd. using only the elements defined in feature.xsd.
The following sections describe four shapes that can be defined in The following sections describe four shapes that can be defined in
GML, and show the equivalent representation in 3GPP MLP [4]. GML, and show the equivalent representation in 3GPP MLP [4].
5.1 Arc band 6.1 Arc band
Arc band is used primarily where timing advance (TA) information is Arc band is used primarily where timing advance (TA) information is
known. Timing advance is a mechanism used in wireless communications known. Timing advance is a mechanism used in wireless communications
to help ensure that handsets and base-stations remained synchronized. to help ensure that handsets and base-stations remained synchronized.
Timing advance is stepped based on signal propagation and is fairly Timing advance is stepped based on signal propagation and is fairly
deterministic, for GSM each increase in TA value represents 553.85 deterministic, for GSM each increase in TA value represents 553.85
metres. metres.
The arc band type was developed to represent the area between two The arc band type was developed to represent the area between two
successive TA values and an antenna opening. This is presented in successive TA values and an antenna opening. This is presented in
skipping to change at page 16, line 35 skipping to change at page 18, line 37
being used, and how to interpret it is important, and this 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 particularly true if the shape must also be validated as is the case
above. above.
Ensuring the legality of this shape type when represented in GML is 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 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 its validity can be assessed. Users of this shape type may be better
served by a formal shape definition being introduced into GeoPriv so served by a formal shape definition being introduced into GeoPriv so
that these problems can be more readily overcome. that these problems can be more readily overcome.
5.2 Ellipsoid Point With Uncertainty Circle 6.2 Ellipsoid Point With Uncertainty Circle
This shape type is used extensively over the North American NENA This shape type is used extensively over the North American NENA
defined E2 interface for transporting mobile geodetic location from defined E2 interface for transporting mobile geodetic location from
the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is 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 defined as a WGS-84 point (ellipsoid point), and a radius or
uncertainty around that point, specified in metres. The 3GPP MLP uncertainty around that point, specified in metres. The 3GPP MLP
representation for an ellipsoid point with uncertainty is defined as representation for an ellipsoid point with uncertainty is defined as
follows: follows:
<pd> <pd>
skipping to change at page 19, line 7 skipping to change at page 21, line 7
This type does not have all of the problems associated with the arc 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 band representation, in that the radius of the circle is relative to
the centre, and so the validation is unnecessary. However it does the centre, and so the validation is unnecessary. However it does
suffer from the potential problem that the application still needs to suffer from the potential problem that the application still needs to
determine the type of uncertainty being represented, though this determine the type of uncertainty being represented, though this
maybe made more clear through the explicit use of the gml: maybe made more clear through the explicit use of the gml:
CircleByCenterPoint element. CircleByCenterPoint element.
5.3 Polygon 6.3 Polygon
A polygon is defined as a set of points to form an enclosed bounded 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. shape. It is here that GML and the 3GPP shapes are most similar.
The representation for a polygon in GML is given first: The representation for a polygon in GML is given first:
<?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:gml="http://opengis.net/gml"
skipping to change at page 21, line 5 skipping to change at page 23, line 5
</outerBoundaryIs> </outerBoundaryIs>
</Polygon> </Polygon>
</shape> </shape>
</pd> </pd>
While these two representations are very similar and precise, they While these two representations are very similar and precise, they
are not widely used at present. If only a coverage area is required are not widely used at present. If only a coverage area is required
without a nominal central point requiring specification, then this without a nominal central point requiring specification, then this
form is ideal for representation using GML. form is ideal for representation using GML.
6. Baseline Geometry 7. Baseline Geometry
PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of
the available GML functionality. As a consequence a number of the available GML functionality. As a consequence a number of
further XML files are implicitly included, namely further XML files are implicitly included, namely
geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd, geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd,
measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and
basicTypes.xsd, as being necessary to support. This provides for a basicTypes.xsd, as being necessary to support. This provides for a
vast range of possibilities which would pose significant vast range of possibilities which would pose significant
complications to implementors wish to develop location dependent complications to implementors wish to develop location dependent
routing applications. By agreeing to a minimal set of data routing applications. By agreeing to a minimal set of data
appropriate for routing, a minimum set of GML that MUST be appropriate for routing, a minimum set of GML that MUST be
implemented by a given application type can also be set. This does implemented by a given application type can also be set. This does
not preclude the additional functionality from being implemented, not preclude the additional functionality from being implemented,
merely that it may not be understood by some nodes. merely that it may not be understood by some nodes.
6.1 Zero Dimensions 7.1 Zero Dimensions
The minimum supported set of elements is position/Point/pos provided The minimum supported set of elements is position/Point/pos provided
by geometryBasic0d1d.xsd. by geometryBasic0d1d.xsd.
Thus a point location has only one representation as follows: Thus a point location has only one representation as follows:
<gml:position xmlns:gml="http://www.opengis.net/gml"> <gml:position xmlns:gml="http://www.opengis.net/gml">
<gml:Point srsName="urn:ogc:def:crs:EPSG:4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>4.5 -36.2</gml:pos> <gml:pos>4.5 -36.2</gml:pos>
</gml:Point> </gml:Point>
skipping to change at page 21, line 43 skipping to change at page 23, line 43
The <location> and <coord> objects MUST NOT be used since they are The <location> and <coord> objects MUST NOT be used since they are
deprecated in GML 3.1 and their functionality can be substituted with deprecated in GML 3.1 and their functionality can be substituted with
the above-described elements. the above-described elements.
Note that pos allows altitude to be expressed based on the selected 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 (e.g., EPSG:4979 or EPSG:4326). Most
Coordinate Reference Systems use altitude above the geoid and not Coordinate Reference Systems use altitude above the geoid and not
altitude above the ground. altitude above the ground.
6.2 One Dimensions 7.2 One Dimensions
Support for one dimensional shapes (such as the LineString or the Support for one dimensional shapes (such as the LineString or the
posList object) is not required except as a part of two dimensional posList object) is not required except as a part of two dimensional
shapes. shapes.
geometryBasic0d1d.xsd provides these geometric properties and geometryBasic0d1d.xsd provides these geometric properties and
objects. objects.
6.3 Two Dimensions 7.3 Two Dimensions
The examples previously used were all contructed using elements from The examples previously used were all contructed using elements from
this schema which reuse functionality from geometryBasic2d.xsd. As this schema which reuse functionality from geometryBasic2d.xsd. As
was described earlier the arcband definition in GML is problematic was described earlier the arcband definition in GML is problematic
for producing a closed solid and SHOULD consequently be avoided. As for producing a closed solid and SHOULD consequently be avoided. As
a result of this, elements required exclusively for representing the a result of this, elements required exclusively for representing the
arcband shape have not been included in the minimum supported element arcband shape have not been included in the minimum supported element
set. The minimum element set is therefore restricted to circle and set. The minimum element set is therefore restricted to circle and
polygon. polygon.
skipping to change at page 22, line 42 skipping to change at page 24, line 42
above, is inline with the model used by the 3GPP. above, is inline with the model used by the 3GPP.
Polygon: Polygon:
extentOf/ extentOf/
Polygon/ Polygon/
exterior/ exterior/
LinearRing/ LinearRing/
pos or posList -> Polygon pos or posList -> Polygon
6.4 Three Dimensions 7.4 Three Dimensions
Support for three dimensions is not required Support for three dimensions is not required
6.5 Envelopes 7.5 Envelopes
The Envelope element is a representation of a bounding box and can be The Envelope element is a representation of a bounding box and can be
expressed in two or three dimensions. Defining a space using the expressed in two or three dimensions. Defining a space using the
Envelope element should be done with extreme caution due to Envelope element should be done with extreme caution due to
continuity problems at the extremities of the CRS. In WGS-84, two continuity problems at the extremities of the CRS. In WGS-84, two
envelopes are required at the 180th meridian. The minimum set of envelopes are required at the 180th meridian. The minimum set of
elements required to support an Envelope are: elements required to support an Envelope are:
boundBy/ boundBy/
Envelope/ Envelope/
skipping to change at page 23, line 12 skipping to change at page 25, line 12
Envelope element should be done with extreme caution due to Envelope element should be done with extreme caution due to
continuity problems at the extremities of the CRS. In WGS-84, two continuity problems at the extremities of the CRS. In WGS-84, two
envelopes are required at the 180th meridian. The minimum set of envelopes are required at the 180th meridian. The minimum set of
elements required to support an Envelope are: elements required to support an Envelope are:
boundBy/ boundBy/
Envelope/ Envelope/
upperCorner/ upperCorner/
Point/ Point/
Pos Pos
lowerCorner/ lowerCorner/
Point/ Point/
Pos/ Pos/
6.6 Temporal Dimensions 7.6 Temporal Dimensions
Support for temporal elements is not required Support for temporal elements is not required
6.7 Units of Measure 7.7 Units of Measure
The base SI units as a minimum MUST be supported. For measures of The base SI units as a minimum MUST be supported. For measures of
distance this is metres. The EPSG URN for metres is: distance this is metres. The EPSG URN for metres is:
metres = urn:ogc:def:uom:EPSG:9001:6.6 metres = urn:ogc:def:uom:EPSG:9001:6.6
Angles are frequently expressed in terms of both degrees and radians, Angles are frequently expressed in terms of both degrees and radians,
consequently both MUST be implemented. consequently both MUST be implemented.
degrees = urn:ogc:def:uom:EPSG:9102:6.6 degrees = urn:ogc:def:uom:EPSG:9102:6.6
radians = urn:ogc:def:uom:EPSG:9101:6.6 radians = urn:ogc:def:uom:EPSG:9101:6.6
Further units of measurement are not required. Further units of measurement are not required.
6.8 Coordinate Reference System (CRS) 7.8 Coordinate Reference System (CRS)
There are a very large number of coordinate reference systems in There are a very large number of coordinate reference systems in
existence today, but many are, however, not in widespread use. existence today, but many are, however, not in widespread use.
Existing communications protocols such as those used in both the Existing communications protocols such as those used in both the
ANSI, 3GPP and NENA standards (see [7], [8], [9]) have standardized ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized
on WGS-84. It is recommended for routing purpose that only WGS-84 on WGS-84. It is recommended for routing purpose that only WGS-84
coordinate types MUST be implemented and further that this set be coordinate types MUST be implemented and further that this set be
resatricted to the following: restricted to the following:
WGS84(2D) = urn:ogc:def:crs:EPSG:4326:6.6 WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326
WGS84(3D) = urn:ogc:def:crs:EPSG:4979:6.6 WGS84(3D) = urn:ogc:def:crs:EPSG:6.6:4979
7. Recommendations 8. 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 3 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 gml:position, gml:pos types be used to specify locations when
locations are needed for routing and specifically emergency routing. locations are needed for routing and specifically emergency routing.
Enhancements to GMLv3 feature.xsd may need to be defined to allow Enhancements to GMLv3 feature.xsd may need to be defined to allow
complex shapes types to be specified in a way that makes them easy to complex shapes types to be specified in a way that makes them easy to
distinguish and validate. This is particularly important if the data distinguish and validate. This is particularly important if the data
is to be used during the decision making process of routing signaling is to be used during the decision making process of routing signaling
messages. messages.
Only a limited subset of GML functionality from the feature.xsd Only a limited subset of GML functionality from the feature.xsd
schema is necessary to describe a geodetic location with sufficient schema is necessary to describe a geodetic location with sufficient
precision to allow a routing decision to be made. Restricting both precision to allow a routing decision to be made. Restricting both
the amount of GML that MUST be implemented, and the number of the amount of GML that MUST be implemented, and the number of
variations in which this data can be expressed significantly reduces variations in which this data can be expressed significantly reduces
the likelihood of interoperability issues in the future. Precedents the likelihood of interoperability issues in the future. Precedents
exist in the other communications protocols for restricting CRS types exist in the other communications protocols for restricting CRS types
and representations for the sake of simplicity and interoperability, and representations for the sake of simplicity and interoperability,
and the recommendation is made to adopt similar restrictions for and the recommendation is made to adopt similar restrictions for
mandatory implementable components of GeoPriv. mandatory implementable components of GeoPriv.
8. Security Considerations If Geodetic information is to be provided via DHCP, then a minimum
resolution of 20 bits SHOULD be specified for both the Latitude and
Longitude fields so that sub 100 metre precision is achieved. Where
only two dimensional objects are required polygons SHOULD be used to
express the enclosed area. Where 3 dimensions are required a 3
dimensional bounding box representing a rectangular prism SHOULD be
used with care taken around the 180th meridian.
9. 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.
9. IANA Considerations 10. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
10. Acknowledgments 11. 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. Furthermore, we would like to discussions in the context of PIDF-LO, in particular James Polk and
thanks Jon Peterson as the author of PIDF-LO and Nadine Abbott for Henning Schulzrinne. Furthermore, we would like to thanks Jon
her constructive comments in clarifying some aspects of the document. Peterson as the author of PIDF-LO and Nadine Abbott for her
constructive comments in clarifying some aspects of the document.
11. Open Issues
A future version of this document will describe how geospatial 12. Open Issues
location information carried inside DHCP (see [6]) can be mapped to
GMLv3 elements. Three issues need to addressed with regard to this
mapping:
Coordinate Reference System (CRS): [6] specifies three CRSs, namely Need to get define minimal subset of Civic information that is useful
datum = 1 seems to map to epsg:4327 (used as the srsName of the for routing purposes. May be hard to get normative, but hopefully we
gml:Point structure), datum = 2 and datum = 3 seem to point to the can get something that is generally representative.
same CRS (epsg:4269).
Geospatial Location Information: Location information as specified in Need agreement on minimal set of shape support.
[6] might either specify a point or an area (based on the usage of
latitude resolution, longitude resolution and altitude
resolution). If the altitude attribute is not used then either a
Point or a Circle structure could be used.
Altitude: Altitude can be expressed in two ways: meters and floors. Need to go through the rules to enhance clarity. These rules are
While the mapping of meters from the location information carried highly likely to be important in quite a number of Location Dependent
in DHCP to GML is easy. Expressing floors is more difficult and Routing (LDR) based applications, including ECRIT. General feedback
might require the usage of civic together with geospatial elements is that they are not clear or precise enough yet. Henning has
in PIDF-LO. 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.
12. References 13. References
12.1 Normative references 13.1 Normative references
[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
draft-ietf-geopriv-pidf-lo-03 (work in progress), draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004. September 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
12.2 Informative References 13.2 Informative References
[3] Peterson, J., "A Presence Architecture for the Distribution of [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in Configuration Protocol Option for Coordinate-based Location
progress), September 2004. Configuration Information", RFC 3825, July 2004.
[4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1",
March 2004. March 2004.
[5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [5] 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-06 (work in Information", draft-ietf-geopriv-dhcp-civil-06 (work in
progress), May 2005. progress), May 2005.
[6] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[7] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
[8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal Geographic Technical Specification Group Code Network; Universal
Area Description (GAD)". Geographic Area Description (GAD)".
[9] "NENA Standard for the Implementation of the Wireless Emergency [8] "NENA Standard for the Implementation of the Wireless Emergency
Service Protocol E2 Interface". Service Protocol E2 Interface".
[9] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-04 (work in
progress), February 2005.
[10] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in
progress), September 2004.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Nortel Nortel
Wollongong Wollongong
NSW Australia NSW Australia
Email: winterb@nortel.com Email: winterb@nortel.com
Martin Thomson Martin Thomson
Nortel Nortel
Wollongong Wollongong
NSW Australia NSW Australia
Email: martin.thomson@nortel.com Email: martin.thomson@nortel.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
skipping to change at page 31, line 5 skipping to change at page 34, line 5
Email: martin.thomson@nortel.com Email: martin.thomson@nortel.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
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
location from information encoded into DHCP option 123. The
following section describes how and end-point can take this
information and represent it in a well formed PIDF-LO describing this
geodetic location.
The location information described in RFC-3825 consists of a
latitude, longitude, altitude and datum.
A.1 Latitude and Longitude
The latitude and longitude values are represented in degrees and
decimal degrees. Latitude values are positive if north of the
equator, and negative if south of the equator. Similarly
longitudinal values are positive if east of the Greenwich meridian,
and negative if west of the Greenwich meridian.
The latitude and longitude values are each 34 bit long fields
consisting of a 9 bit integer component and a 25 bit fraction
component, with negative numbers being represented in 2s complement
notation. The latitude and longitude fields are each proceeded by a
6 bit resolution field, the LaRes for latitude, and the LoRes for
longitude. The value in the LaRes field indicates the number of
significant bits to interpret in the Latitude field, while the value
in the LoRes field indicates the number of significant bits to
interpret in the Longitude field.
For example, if you are in Wollongong Australia which is located at
34 Degrees 25 minutes South and 150 degrees 32 minutes East this
would translate to -34.41667, 150.53333 in decimal degrees. If these
numbers are translated to their full 34 bit representations, then we
arrive the following:
Latitude = 111011101.1001010101010101000111010
Longitude = 0100101101000100010001000010100001
RFC-3825, uses the LaRes and LoRes values to specify a lower and
upper boundary for location thereby specifying an area. The size of
the area specified is directly related to the value specified in the
LaRes and LoRes fields.
Using the previous example, if LaRes is set 7, then lower latitude
boundary can be calculated as -256+128+64+16+8+4, which is -36
degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which
is -35 degrees. LoRes may be used similarly for Longitude.
So what level of precision is useful? Well, certain types of
applications and regulations call for different levels of precision,
and the required precision may vary depending on how the location was
determined. For Cellular 911 calls in the United States, for
example, if the network measures the location then the caller should
be within 100 metres, while if the handset does the measurement then
the location should be within 50 metres. Since DHCP is a network
based mechanism we will benchmark off 100 metres (approximately 330
ft) which is still a large area.
For simplicity we shall assume that we are defining a square, in
which we are equally to appear anywhere. The greatest distance
through this square is across the diagonal, so we make this 100
metres.
+----------------------+
| _/|
| _/ |
| _/ |
| _/ |
| _/ |
| 100_/ metres |
| _/ |
| _/ |
| _/ |
| _/ |
|_/ |
+----------------------+
The distance between the top and the bottom and the left and the
right is the same, the area being a square, and this works out to be
70.7 metres. When expressed in decimal degrees, the third point
after the decimal place represents about 100 metre precision, this
equates to 10 binary places of fractional part. A 70 metre distance
is required, so 11 fractional binary digits are necessary resulting
in a total of 20 bits of precision.
With -34.4167, 150.5333 encoded with 20 bits of precision for the
LaRes and LoRes, the corners of the enclosing square are:
Point 1 (-34.4170, 150.5332)
Point 2 (-34.4170, 150.5337)
Point 3 (-34.4165, 150.5332)
Point 4 (-34.4165, 150.5337)
A.2 Altitude
The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either metres, or
floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components.
A.3 Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used. If the
altitude is expressed in floors and is required, the altitude SHOULD
be expressed as a civic floor number as part of the same location-
info element. In the example above the GML for the location would be
expressed as follows:
<gml:extentOf>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList srsName="urn:ogc:def:crs:EPSG:6.6:4326">
-34.4165 150.5332
-34.4165 150.5337
-34.4170 150.5537
-34.4170 150.5532
-34.4165 150.5332
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
If a floor number of say 3 were included, then the location-info
element would contain the above information and the following:
<cl:civilAddress>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
When altitude is expressed as an integer and fractional component, as
with the latitude and longitude, it expresses a range, and this
cannot be easily expressed in polygon form. Envelopes, as described
earlier, define upper and lower bounds for rectangular enclosures,
both in two and 3 dimensions, and SHOULD be used where an altitude
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
metres rather than floors. AltRes is set to a value of 19, and the
Altitude value is set to 34. Using similar techniques as shown in
the latitude and longitude section, a range of altitudes between 32
metres and 40 metres is described. The Envelope would therefore be
defined as follows:
<gml:boundBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:6.6:4976">
<gml:upperCorner>
<gml:Point>
<gml:Pos>-34.4165 150.5337 40</gml:Pos>
</gml:Point>
</gml:upperCorner>
<gml:lowerCorner>
<gml:Point>
<gml:Pos>-34.4170 150.5332 32</gml:Pos>
</gml:Point>
</gml:lowerCorner>
</gml:Envelope>
</gml:boundBy>
The Method value SHOULD be set to DHCP. Note that this case, the
DHCP is referring to the way in which location information was
delivered to the IP-device, and not necessarily how the location was
determined.
The timestamp value SHOULD be set to the time that location was
retrieved from the DHCP server.
The client application MAY insert any usage rules that are pertinent
to the user of the device and that comply with [9]. A guideline is
that the any retention-expiry value SHOULD NOT exceed the current
lease time.
The Provided-By element SHOULD NOT be populated as this is not
provided by the source of the location information.
The 3 completed PIDF-LO representations are provided below, and
represent a location without altitude, a location with a civic
altitude, and a location represented as a 3 dimensional rectangular
prism.
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns: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:ogc:def:crs:EPSG:6.6:4326">
-34.4165 150.5332
-34.4165 150.5337
-34.4170 150.5537
-34.4170 150.5532
-34.4165 150.5332
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
<method>DHCP</method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
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:ogc:def:crs:EPSG:6.6:4326">
-34.4165 150.5332
-34.4165 150.5337
-34.4170 150.5537
-34.4170 150.5532
-34.4165 150.5332
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
<cl:civilAddress>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
<method>DHCP</method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
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:boundBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:6.6:4976">
<gml:upperCorner>
<gml:Point>
<gml:Pos>-34.4165 150.5337 40</gml:Pos>
</gml:Point>
</gml:upperCorner>
<gml:lowerCorner>
<gml:Point>
<gml:Pos>-34.4170 150.5332 32</gml:Pos>
</gml:Point>
</gml:lowerCorner>
</gml:Envelope>
</gml:boundBy>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
<method>DHCP</method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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