Geopriv J. Winterbottom Internet-Draft M. Thomson Updates: 4119 (if approved) Andrew Corporation Intended status: Standards Track H. Tschofenig Expires: December 31, 2007 Nokia Siemens Networks June 29, 2007 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations draft-ietf-geopriv-pdif-lo-profile-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Winterbottom, et al. Expires December 31, 2007 [Page 1]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Abstract The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise 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 make use of it are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that is mandatory to implemented by applications involved in location based routing. Winterbottom, et al. Expires December 31, 2007 [Page 2]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Using Location Information . . . . . . . . . . . . . . . . . . 6 3.1. Single Civic Location Information . . . . . . . . . . . . 8 3.2. Civic and Geospatial Location Information . . . . . . . . 8 3.3. Manual/Automatic Configuration of Location Information . . 9 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 21 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative references . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Winterbottom, et al. Expires December 31, 2007 [Page 3]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 1. Introduction The Presence Information Data Format Location Object (PIDF-LO) [2] is the recommended way of encoding location information and associated privacy policies. Location information in a PIDF-LO may be described in a geospatial manner based on a subset of GMLv3, or as civic location information [6]. A GML profile for expressing geodetic shapes in a PIDF-LO is described in [4]. 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. The PIDF-LO provides a general presence format for representing location information, and permits specification of location information relating to a whole range of aspects of a Target. The general presence data model is described in [3] and caters for a presence document to describe different aspects of the reachability of a presentity. Continuing this approach, a presence document may contain several geopriv objects that specify different locations and aspects of reachability relating to a presentity. This degree of flexibility is important, and and recommendations in this document make no attempt to forbid the usage of a PIDF-LO in this manner. This document provides a specific set of guidelines for building preence documents when it is important to unambiguously convey exactly one location. Winterbottom, et al. Expires December 31, 2007 [Page 4]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. The definition for "Target" is taken from [7]. In this document a "discrete location" is defined as a place, point, area or volume in which a Target can be found. It must be described with sufficient precision to address the requirements of an intended application. The term "compound location" is used to describe location information represented by a composite of both civic and geodetic information. An example of compound location might be a geodetic polygon describing the perimeter of a building and a civic element representing the floor in the building. The term _method_ is this document refers to the mechanism used to determine the location of a Target. This may be something employed by an LCS, or by the Target itself. It specifically does not refer to the LCP used to deliver location information either to the Target or the Recipient. The term _source_ is used to refer to the LCS, node or device from which a Recipient (Target or Third-Party) obtains location information/ Winterbottom, et al. Expires December 31, 2007 [Page 5]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 3. Using Location Information The PIDF format provides for an unbounded number of <tuple> elements. Each <tuple> element contains a single <status> element that may contain more than one <geopriv> element as a child element. Each <geopriv> element must contain at least the following two child elements: <location-info> element and <usage-rules> element. One or more chunks of location information are contained inside a <location- info> element. Hence, a single PIDF document may contain an arbitrary number of location objects some or all of which may be contradictory or complementary. Graphically, the structure of a PIDF-LO document can be depicted as shown in Figure 1. <?xml version="1.0" encoding="UTF-8"?> <presence> <tuple> -- #1 <status> <geopriv> -- #1 <location-info> location chunk #1 location chunk #2 ... location chunk #n <usage-rules> </geopriv> <geopriv> -- #2 <geopriv> -- #3 ... <geopriv> -- #m </status> </tuple> <tuple> -- #2 <tuple> -- #3 ... <tuple> -- #o </presence> Figure 1: Structure of a PIDF-LO Document All of these potential sources and storage places for location lead to confusion for the generators, conveyors and consumers of location information. Practical experience within the United States National Emergency Number Association (NENA) in trying to solve these ambiguities led to a set of conventions being adopted. These rules Winterbottom, et al. Expires December 31, 2007 [Page 6]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 do not have any particular order, but should be followed by creators and consumers of location information contained in a PIDF-LO to ensure that a consistent interpretation of the data can be achieved. Rule #1: A <geopriv> element MUST describe a discrete location. Rule #2: Where a discrete location can be uniquely described in more than one way, each location description SHOULD reside in a separate <tuple> element. Rule #3: Providing more than one geopriv element in a single presence document (PIDF) MUST only be done if all objects refer to the same place. This may occur if a Target's location is determined using a series of different techniques. Rule #4: Providing more than one location chunk in a single <location-info> element SHOULD be avoided where possible. Rule #5 and Rule #6 provide further refinement. Rule #5: When providing more than one location chunk in a single <location-info> element the locations MUST be provided by a common source at the same time and by the same location determination method. Rule #6: Providing more than one location chunk in a single <location-info> element SHOULD only be used for representing compound location referring to the same place. For example, a geodetic location describing a point, and a civic location indicating the floor in a building. Rule #7: Where compound location is provided in a single <location- info> element, the coarse location information MUST be provided first. For example, a geodetic location describing an area, and a civic location indicating the floor should be represented with the area first followed by the civic location. Winterbottom, et al. Expires December 31, 2007 [Page 7]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Rule #8: Where a PIDF document contains more than one <tuple> element containing a <status> element with a <geopriv> element, the priority of tuples SHOULD be based on position of the <tuple> element within the PIDF document. That is to say, the tuple with the highest priority location occurs earliest in the PIDF document. Rule #9: Where multiple PIDF documents can be sent or received together, say in a multi-part MIME body, and current location information is required by the recipient, then document selection SHOULD be based on document order, with the first document considered first. The following examples illustrate the application of these rules. 3.1. Single Civic Location Information 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 WiFi hotspot, Jane obtains a complete civic address for her current location, for example using the DHCP civic mechanism defined in [5]. A Location Object is constructed consisting of a single PIDF document, with a single <tuple> element, a single <status> element, a single <geopriv> element, and a single location chunk residing in the <location-info> element. This document is unambiguous, and should be interpreted consistently by receiving nodes if sent over the network. 3.2. Civic and Geospatial Location Information Mike is visiting his Seattle office and connects his laptop into the Ethernet port in a spare cube. In this case location information is geodetic location, with the altitude represented as a building floor number. Mike's main location is the point specified by the geodetic coordinates. Further, Mike is on the second floor of the building located at these coordinates. Applying rules #6 and #7, the resulting compound location information is shown below. Winterbottom, et al. Expires December 31, 2007 [Page 8]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:mike@seattle.example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326" <gml:pos>-43.5723 153.21760</gml:pos> </gml:Point> <cl:civicAddress> <cl:FLR>2</cl:FLR> </cl:civicAddress> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> </presence> 3.3. Manual/Automatic Configuration of Location Information Loraine has a predefined civic location stored in her laptop, since she normally lives in Sydney, the address is for her Sydney-based apartment. Loraine decides to visit sunny San Francisco, and when she gets there she plugs in her laptop and makes a call. Loraine's laptop receives a new location from the visited network in San Francisco. As this system cannot be sure that the pre-existing, and new location, describe the same place, Loraine's computer generates a new PIDF-LO and will use this to represent Loraine's location. If Loraine's computer were to add the new location to her existing PIDF location document (breaking rule #3), then the correct information may still be interpreted by the 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 the tuple containing the San Francisco location first. Winterbottom, et al. Expires December 31, 2007 [Page 9]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 4. Geodetic Coordinate Representation The geodetic examples provided in RFC 4119 [2] are illustrated using the <gml:location> element, which uses the <gml:coordinates> element inside the <gml:Point> element and this representation has several drawbacks. Firstly, it has been deprecated in later versions of GML (3.1 and beyond) making it inadvisable to use for new applications. Secondly, the format of the coordinates type is opaque and so can be difficult to parse and interpret to ensure consistent results, as the same geodetic location can be expressed in a variety of ways. The PIDF-LO Geodetic Shapes specification [4] provides a specific GML profile for expressing commonly used shapes using simple GML representations. The shapes defined in [4] are the recommended shapes to ensure interoperability. Winterbottom, et al. Expires December 31, 2007 [Page 10]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 5. Geodetic Shape Representation The cellular mobile world today makes extensive use of geodetic based location information for emergency and other location-based applications. Generally these locations are expressed as a point (either in two or three dimensions) and an area or volume of uncertainty around the point. In theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume. In practice, most systems use the point as an absolute value and ignore the uncertainty. It is difficult to determine if systems have been implemented in this manner for simplicity, and even more difficult to predict if uncertainty will play a more important role in the future. An important decision is whether an uncertainty area should be specified. The PIDF-LO Geodetic Shapes specification [4] defines eight shape types most of which are easily translated into shapes definitions used in other applications and protocols, such as Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For completeness the shapes defined in [4] are listed below: o Point (2d and 3d) o Polygon (2d) o Circle (2d) o Ellipse (2d) o Arc band (2d) o Sphere (3d) o Ellipsoid (3d) o Prism (3d) All above-listed shapes are mandatory to implement. The GeoShape specification [4] also describes a standard set of coordinate reference systems (CRS), unit of measure (UoM) and conventions relating to lines and distances. The use of the WGS-84 coordinate reference system and the usage of EPSG-4326 (as identified by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape representations and EPSG-4979 (as identified by the URN urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume Winterbottom, et al. Expires December 31, 2007 [Page 11]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 representations is mandated. Distance and heights are expressed in meters using EPSG-9001 (as identified by the URN urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either degrees or radians. Measures in degrees MUST be identified by the URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be identified by the URN urn:ogc:def:uom:EPSG::9101 Implementations MUST specify the CRS using the srsName attribute on the outermost geometry element. The CRS MUST NOT be respecified or changed for any sub-elements. The srsDimension attribute SHOULD be omitted, since the number of dimensions in these CRSs is known. A CRS MUST be specified using the above URN notation only, implementations do not need to support user-defined CRSs. It is RECOMMENDED that where uncertainty is included, a confidence of 68% (or one standard deviation) is used. Specifying a convention for confidence enables better use of uncertainty values. 5.1. Polygon Restrictions The Polygon shape type defined in [4] intentionally does not place any constraints on the number of vertices that may be included to define the bounds of a polygon. This allows arbitrarily complex shapes to be defined and conveyed in a PIDF-LO. However, where location information is to be used in real-time processing applications, such as location dependent routing, having arbitrarily complex shapes consisting of tens or even hundreds of points could result in significant performance impacts. To mitigate this risk it is recommended that Polygon shapes be restricted to a maximum of 15 points (16 including the repeated point) when the location information is intended for use in real-time applications. This limit of 15 points is chosen to allow moderately complex shape definitions while at the same time enabling interoperation with other location transporting protocols such as those defined in 3GPP (see [9]) and OMA where the 15 point limit is already imposed. Polygons are defined with the minimum distance between two adjacent vertices (geodesic). To avoid the incursion of significant errors length between adjacent vertices SHOULD be restricted to a maximum of 130km. More information relating to this restriction is provided in [4]. A connecting line SHALL NOT cross another connecting line of the same Polygon. Polygons SHOULD be defined with the upward normal pointing up, this is accomplished by defining the vertices in counter-clockwise direction. Winterbottom, et al. Expires December 31, 2007 [Page 12]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Points specified in a polygon MUST be coplanar, and it is RECOMMENDED that where points are specified in 3 dimensions that all points maintain the same altitude. 5.2. Shape Examples This section provides some examples of where some of the more complex shapes are used, how they are determined, and how they are represented in a PIDF-LO. Complete details on all of the Geoshape types are provided in [4]. 5.2.1. Point The point shape type is the simplest form of geodetic LI, which is natively supported by GML. The gml:Point element is used when there is no known uncertainty. A point also forms part of a number of other geometries. A point may be specified using either WGS 84 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). The next example shows a 2d point: <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:point2d@example.com"> <tuple id="sg89abcd"> <status> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>-34.407 150.883</gml:pos> </gml:Point> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence> The next example shows a 3d point: Winterbottom, et al. Expires December 31, 2007 [Page 13]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:point3d@example.com"> <tuple id="sg89ab5"> <status> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4979" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>-34.407 150.883 24.8</gml:pos> </gml:Point> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence> 5.2.2. Polygon The polygon shape may be used to represent a building outline or coverage area. The first and last points of the polygon have to be the same. For example, looking at the octagon below with vertices, A, H, G, F, E, D, C, B, A. The resulting polygon will be defined with 9 points, with the first and last points both having the coordinates of point A. B-------------C / \ / \ / \ A D | | | | | | | | H E \ / \ / \ / G--------------F Winterbottom, et al. Expires December 31, 2007 [Page 14]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:octagon@example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:pos>43.311 -73.422</gml:pos> <!--A--> <gml:pos>43.211 -73.422</gml:pos> <!--H--> <gml:pos>43.111 -73.322</gml:pos> <!--G--> <gml:pos>43.111 -73.222</gml:pos> <!--F--> <gml:pos>43.211 -73.122</gml:pos> <!--E--> <gml:pos>43.311 -73.122</gml:pos> <!--D--> <gml:pos>43.411 -73.222</gml:pos> <!--C--> <gml:pos>43.411 -73.322</gml:pos> <!--B--> <gml:pos>43.311 -73.422</gml:pos> <!--A--> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence> Figure 6 In addition to the form shown in Figure 6 GML supports a posList which provides a more compact representation for the coordinates of the Polygon vertices than the discrete pos elements. The more compact form is shown in Figure 7. Both forms are permitted. Winterbottom, et al. Expires December 31, 2007 [Page 15]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:octagon@example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:posList>43.311 -73.422 43.211 -73.422 43.111 -73.322 43.111 -73.222 43.211 -73.122 43.311 -73.122 43.411 -73.222 43.411 -73.322 43.311 -73.422 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence> Figure 7 5.2.3. Circle The circular area is used for coordinates in two-dimensional CRSs to describe uncertainty about a point. The definition is based on the one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre point of a circular area is specified by using a two dimensional CRS; in three dimensions, the orientation of the circle cannot be specified correctly using this representation. A point with uncertainty that is specified in three dimensions should use the Sphere shape type. Winterbottom, et al. Expires December 31, 2007 [Page 16]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:circle@example.com"> <tuple id="sg89ab1"> <status> <gp:geopriv> <gp:location-info> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos> 42.5463 -73.2512 </gml:pos> <gml:radius uom="urn:ogc:def:uom:EPSG::9001"> 850.24 </gml:radius> </gs:Circle> </gp:location-info> </gp:geopriv> </status> </tuple> </presence> 5.2.4. Ellipse An elliptical area describes an ellipse in two dimensional space. The ellipse is described by a center point, the length of its semi- major and semi-minor axes, and the orientation of the semi-major axis. Like the circular area (Circle), the ellipse MUST be specified using the two dimensional CRS. Winterbottom, et al. Expires December 31, 2007 [Page 17]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:Ellipse@somecell.example.com"> <tuple id="sg89ab7"> <status> <gp:geopriv> <gp:location-info> <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos> 42.5463 -73.2512 </gml:pos> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> 1275 </gs:semiMajorAxis> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> 670 </gs:semiMinorAxis> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> 43.2 </gs:orientation> </gs:Ellipse> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> </presence> The gml:pos element indicates the position of the center, or origin, of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements are the length of the semi-major and semi-minor axes respectively. The gs:orientation element is the angle by which the semi-major axis is rotated from the first axis of the CRS towards the second axis. For WGS 84, the orientation indicates rotation from Northing to Easting, which, if specified in degrees, is roughly equivalent to a compass bearing (if magnetic north were the same as the WGS north pole). Note: An ellipse with equal major and minor axis lengths is a circle. Winterbottom, et al. Expires December 31, 2007 [Page 18]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 5.2.5. Arc Band The arc band shape type is commonly generated in wireless systems where timing advance or code offsets sequences are used to compensate for distances between handsets and the access point. The arc band is represented as two radii emanating from a central point, and two angles which represent the starting angle and the opening angle of the arc. In a cellular environment the central point is nominally the location of the cell tower, the two radii are determined by the extent of the timing advance, and the two angles are generally provisioned information. For example, Paul is using a cellular wireless device and is 7 timing advance symbols away from the cell tower. For a GSM-based network this would place Paul roughly between 3,594 meters and 4,148 meters from the cell tower, providing the inner and outer radius values. If the start angle is 20 degrees from north, and the opening angle is 120 degrees, an arc band representing Paul's location would look similar to the figure below. N ^ ,.__ | a(s) / `-. | 20 / `-. |--. / `. | `/ \ | /__ \ | . `-. \ | . `. \ |. \ \ . ---c-- a(o) -- | | --> |. / 120 ' | E | . / ' | . / ; .,' / r(i)`. / (3594m) `. / `. ,' `. ,' r(o)`' (4148m) The resulting PIDF-LO is reflected below. Winterbottom, et al. Expires December 31, 2007 [Page 19]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:paul@somecell.example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos> -43.5723 153.21760 </gml:pos> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> 3594 </gs:innerRadius> <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001"> 4148 </gs:outerRadius> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> 20 </gs:startAngle> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> 20 </gs:openingAngle> </gs:ArcBand> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> </presence> An important note to make on the arc band is that the center point used in the definition of the shape is not included in resulting enclosed area, and that Target may be anywhere in the defined area of the arc band. 5.2.6. Sphere The sphere is a volume that provides the same information as a circle in three dimensions. The sphere has to be specified using a three dimensional CRS. The following example shows a sphere shape, which is identical to the circle example, except for the addition of an Winterbottom, et al. Expires December 31, 2007 [Page 20]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 altitude in the provided coordinates. <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:circle@example.com"> <tuple id="sg89ab1"> <status> <gp:geopriv> <gp:location-info> <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos> 42.5463 -73.2512 26.3 </gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> 850.24 </gs:radius> </gs:Sphere> </gp:location-info> </gp:geopriv> </status> </tuple> </presence> 5.2.7. Ellipsoid The ellipsoid is the volume most commonly produced by GPS systems. It is used extensively in navigation systems and wireless location networks. The ellipsoid is constructed around a central point specified in three dimensions, and three axies perpendicular to one another are extended outwards from this point. These axies are defined as the semi-major (M) axis, the semi-minor (m) axis, and the vertical (v) axis respectively. An angle is used to express the orientation of the ellipsoid. The orientation angle is measured in degrees from north, and represents the direction of the semi-major axis from the center point. Winterbottom, et al. Expires December 31, 2007 [Page 21]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 \ _.-\""""^"""""-._ .' \ | `. / v m \ | \ | | | -c ----M---->| | | \ / `._ _.' `-...........-' A PIDF-LO containing an ellipsoid would like something like the sample below. Winterbottom, et al. Expires December 31, 2007 [Page 22]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:somone@gpsreceiver.example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos> 42.5463 -73.2512 26.3 </gml:pos> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> 7.7156 </gs:semiMajorAxis> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> 3.31 </gs:semiMinorAxis> <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001"> 28.7 </gs:verticalAxis> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> 90 </gs:orientation> </gs:Ellipsoid> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> </presence> 5.2.8. Prism A prism may be used to represent a section of a building or range of floors of building. The prism extrudes a polygon by providing a height element. It consists of a base made up of coplanar points defined in 3 dimensions all at the same altitude. The prism is then an extrusion from this base to the value specified in the height element. If the height is negative, then the prism is extruded from the top down, while a positive height extrudes from the bottom up. The first and last points of the polygon have to be the same. Winterbottom, et al. Expires December 31, 2007 [Page 23]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 For example, looking at the cube below. If the prism is extruded from the bottom up, then the polygon forming the base of the prism is defined with the points A, B, C, D, A. The height of the prism is the distance between point A and point E in meters. The resulting PIDF-LO is provided below. G-----F /| /| / | / | H--+--E | | C--|--B | / | / |/ |/ D-----A Winterbottom, et al. Expires December 31, 2007 [Page 24]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml" entity="pres:mike@someprism.example.com"> <tuple id="sg89ab"> <status> <gp:geopriv> <gp:location-info> <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> <gs:base> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList> 42.556844 -73.248157 36.6 <!--A--> 42.656844 -73.248157 36.6 <!--B--> 42.656844 -73.348157 36.6 <!--C--> 42.556844 -73.348157 36.6 <!--D--> 42.556844 -73.248157 36.6 <!--A--> </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gs:base> <gs:height uom="urn:ogc:def:uom:EPSG::9001"> 2.4 </gs:height> </gs:Prism> </gp:location-info> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence> Winterbottom, et al. Expires December 31, 2007 [Page 25]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 6. Security Considerations The primary security considerations relate to how location information is conveyed and used, which are outside the scope of this document. This document is intended to serve only as a set of guidelines as to which elements MUST or SHOULD be implemented by systems wishing to perform location dependent routing. The ramification of such recommendations is that they extend to devices and clients that wish to make use of such services. Winterbottom, et al. Expires December 31, 2007 [Page 26]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 7. IANA Considerations This document does not introduce any IANA considerations. Winterbottom, et al. Expires December 31, 2007 [Page 27]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 8. Acknowledgments The authors would like to thank the GEOPRIV working group for their discussions in the context of PIDF-LO, in particular Carl Reed, Ron Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall and Robert Sparks. Furthermore, we would like to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for her constructive comments in clarifying some aspects of the document. Winterbottom, et al. Expires December 31, 2007 [Page 28]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 9. References 9.1. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [3] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [4] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142, Version: 0.0.9, December 2006. 9.2. Informative References [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. [6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in progress), February 2007. [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [8] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; Technical Specification Group Code Network; Universal Geographic Area Description (GAD)". Winterbottom, et al. Expires December 31, 2007 [Page 29]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Authors' Addresses James Winterbottom Andrew Corporation Wollongong NSW Australia Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation Wollongong NSW Australia Email: martin.thomson@andrew.com Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Winterbottom, et al. Expires December 31, 2007 [Page 30]
Internet-Draft GEOPRIV PIDF-LO Profile June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Winterbottom, et al. Expires December 31, 2007 [Page 31]
