One document matched: draft-ietf-geopriv-pdif-lo-profile-11.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC3693 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC4776 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml">
<!ENTITY RFC4479 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml">
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-geopriv-revised-civic-lo PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-revised-civic-lo.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes"?>
<rfc ipr="full3978" category="std" updates="4119"
docName="draft-ietf-geopriv-pdif-lo-profile-11.txt">
<front>
<title abbrev="GEOPRIV PIDF-LO Profile">GEOPRIV PIDF-LO Usage Clarification, Considerations
and Recommendations </title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street/>
<code/>
<city>Wollongong</city>
<country>NSW Australia</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street/>
<code/>
<city>Wollongong</city>
<country>NSW Australia</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date month="February" year="2008"/>
<area>RAI</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> 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. In these circumstances the range of options that need to be implemented 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 implement by
applications involved in location based routing. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> The Presence Information Data Format Location Object (PIDF-LO) <xref target="RFC4119"/>
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 <xref
target="I-D.ietf-geopriv-revised-civic-lo"/>. A GML profile for expressing geodetic
shapes in a PIDF-LO is described in <xref target="GeoShape"/>. 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.
</t>
<t>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 <xref target="RFC4479"/> 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 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 presence
documents when it is important to unambiguously convey exactly one location.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t> 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
<xref target="RFC2119"/>. </t>
<t> The definition for "Target" is taken from <xref target="RFC3693"/>.
</t>
<t>In this document a "discrete location" is defined as a place, point,
area or volume in which a Target can be found.
</t>
<t>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.
</t>
<t>The term "method" in this document refers to the mechanism used to determine
the location of a Target. This may be something employed by a LIS, 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.
</t>
<t>The term "source" is used to refer to the LIS, node or device from which a Recipient (Target or Third-Party)
obtains location information.
</t>
</section>
<!-- ____________________________________________________________
RULES DEFINITION
____________________________________________________________
-->
<section anchor="rules" title="Using Location Information">
<t> The PIDF format provides for an unbounded number of <tuple>, <device>, and <person> elements.
Each of these elements contains a single <status> element that
may contain more than one <geopriv> element as a child. 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. </t>
<t>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 <xref target="pidf-lo"/>.</t>
<figure anchor="pidf-lo" title="Structure of a PIDF-LO Document">
<artwork><![CDATA[
<?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>
<device>
<status>
<geopriv> -- #1
<location-info>
location chunk #1
location chunk #2
...
location chunk #n
<usage-rules>
</geopriv>
<geopriv> -- #2
<geopriv> -- #3
...
<geopriv> -- #m
</status>
</device>
<person>
<status>
<geopriv> -- #1
<location-info>
location chunk #1
location chunk #2
...
location chunk #n
<usage-rules>
</geopriv>
<geopriv> -- #2
<geopriv> -- #3
...
<geopriv> -- #m
</status>
</person>
<tuple> -- #2
<device> -- #2
<person> -- #2
...
<tuple> -- #o
</presence>
]]></artwork>
</figure>
<t> 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 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. </t>
<t>
<list style="hanging">
<t hangText="Rule #1:"> A <geopriv> element MUST describe a discrete
location. <vspace blankLines="1"/>
</t>
<t hangText="Rule #2:"> Where a discrete location can be uniquely described in more
than one way, each location description SHOULD reside in a separate
<tuple>, <device>, or <person> element.<vspace blankLines="1"/>
</t>
<t hangText="Rule #3:"> Providing more than one <geopriv> element in a single presence
document (PIDF) MUST only be done if the locations refer to the same place or are put into different element types.
For example, one location in a <tuple>, a second location in a <device> element, and a third location in a <person> element.<list
style="empty">
<t>This may occur if a Target's location is determined using a series of
different techniques, or the Target wishes to represent her location as well as the location of her PC.
In general avoid putting more than one location into a document unless it makes sense to do so.
</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="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. <vspace blankLines="1"/>
</t>
<t hangText="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. <vspace
blankLines="1"/>
</t>
<t hangText="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. <list style="empty">
<t>For example, a geodetic location describing a point, and a civic location
indicating the floor in a building.</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Rule #7:"> Where compound location is provided in a single
<location-info> element, the coarse location information MUST be
provided first. <list style="empty">
<t>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.</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Rule #8:"> Where a PIDF document contains more than one
<geopriv> element, the priority of interpretation is given to the first <device> element in the document containing a location.
If no <device> element containing a location is present in the document, then priority is given to the first <tuple> element
containing a location. Locations contained in <person> tuples SHOULD only be used as a last resort.
<vspace blankLines="1"/>
</t>
<t hangText="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. </t>
</list>
</t>
<t> The following examples illustrate the application of these rules. </t>
<!-- ____________________________________________________________
RULES EXAMPLE 1
____________________________________________________________
-->
<section anchor="example1" title="Single Civic Location Information">
<t> 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 <xref target="RFC4776"/>. A Location Object is constructed consisting of a
single PIDF document, with a single <tuple> or <device> 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. </t>
</section>
<!-- ____________________________________________________________
END RULES EXAMPLE 1
____________________________________________________________
-->
<!-- ____________________________________________________________
RULES EXAMPLE 2
____________________________________________________________
-->
<section anchor="example2" title="Civic and Geospatial Location Information">
<t> 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 in <xref target="compound"/>. </t>
<figure anchor="compound">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:mike@seattle.example.com">
<dm:device id="mikepc">
<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/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
</dm:device>
</presence>
]]></artwork>
</figure>
</section>
<!-- ____________________________________________________________
END RULES EXAMPLE 2
____________________________________________________________
-->
<!-- ____________________________________________________________
RULES EXAMPLE 3
____________________________________________________________
-->
<section anchor="example3" title="Manual/Automatic Configuration of Location Information">
<t> 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,
both 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. </t>
</section>
<!-- ____________________________________________________________
END RULES EXAMPLE 3
____________________________________________________________
-->
<section anchor="example4" title="Multiple Location Objects in a Single PIDF-LO">
<t>Vanessa has her PC with her at the park, but due to a misconfiguration, her PC reports her
location as being in the office. The resulting PIDF-LO will have a <device> element
showing the location of Vanessa's PC as the park, and a <person> element saying that
Vanessa is in her office.
</t>
<figure anchor="multipleli">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<dm:device id="nesspc-1">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.410649 150.87651</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
30
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<method>GPS</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
<dm:person id="ness">
<status>
<gp:geopriv>
<gp:location-info>
<civicAddress xml:lang="en-AU">
<country>AU</country>
<A1>NSW</A1>
<A3> Wollongong
</A3><A4>North Wollongong
</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<LMK>
Gilligan's Island
</LMK> <LOC>Corner</LOC>
<NAM> Main Bank </NAM>
<PC>2500</PC>
<ROOM> 398 </ROOM>
<PLC>store</PLC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
</gp:location-info>
<gp:usage-rules/>
<method>Manual</method>
</gp:geopriv>
</status>
<timestamp>2007-06-24T12:28:04Z</timestamp>
</dm:person>
</presence>
]]></artwork>
</figure>
</section>
</section>
<!-- ____________________________________________________________
END RULES DEFINITION
____________________________________________________________
-->
<!-- ____________________________________________________________
GEODETIC SPECIFICATIONS
____________________________________________________________
-->
<section title="Geodetic Coordinate Representation">
<t> The geodetic examples provided in RFC 4119 <xref target="RFC4119"/> 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 <xref
target="GeoShape"/> provides a specific GML profile for expressing commonly used
shapes using simple GML representations. The shapes defined in <xref target="GeoShape"/>
are the recommended shapes to ensure interoperability. </t>
</section>
<section title="Geodetic Shape Representation">
<t> 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. </t>
<t>The PIDF-LO Geodetic Shapes specification <xref target="GeoShape"/> 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 <xref target="GeoShape"/> are listed
below: <list style="symbols">
<t>Point (2d and 3d)</t>
<t>Polygon (2d)</t>
<t>Circle (2d)</t>
<t>Ellipse (2d)</t>
<t>Arc band (2d)</t>
<t>Sphere (3d)</t>
<t>Ellipsoid (3d)</t>
<t>Prism (3d)</t>
</list>
</t>
<t>All above-listed shapes are mandatory to implement. </t>
<t>The GeoShape specification <xref target="GeoShape"/> 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 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 </t>
<t>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.</t>
<t>It is RECOMMENDED that where uncertainty is included, a confidence of 95% is used. Specifying a convention for confidence enables better use of uncertainty values.</t>
<section title="Polygon Restrictions">
<t> The Polygon shape type defined in <xref target="GeoShape"/> 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 <xref target="3GPP-TS-23_032"/>) and OMA where the 15 point
limit is already imposed. </t>
<t>The edges of a polygon are defined by the shortest path between two points in space (not a geodesic curce).
To avoid significant errors arising from potential geodesic interpolation, the length between
adjacent vertices SHOULD be restricted to a maximum of 130km. More information relating to this
restriction is provided in <xref target="GeoShape"/>.
</t>
<t>A connecting line SHALL NOT cross another connecting line of the same
Polygon.
</t>
<t>Polygons SHOULD be defined with the upward normal pointing up. This is
accomplished by defining the vertices in a counter-clockwise direction.
</t>
<t> 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.
</t>
</section>
<section title="Shape Examples">
<t>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 <xref target="GeoShape"/>. </t>
<section title="Point">
<t> 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). <xref target="point2d"/> shows a 2d point:</t>
<figure anchor="point2d">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</gp:location-info>
<gp:usage-rules/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
</presence>
]]></artwork>
</figure>
<figure anchor="point3d">
<preamble><xref target="point3d"/> shows a 3d point:</preamble>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:point3d@example.com">
<dm:device id="point3d">
<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/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
</presence>
]]></artwork>
</figure>
</section>
<section title="Polygon">
<t> 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 hexagon in <xref target="samplepoly"/> with vertices, A, B, C, D, E, and F. The resulting
polygon will be defined with 7 points, with the first and last points both having
the coordinates of point A.</t>
<figure anchor="samplepoly">
<artwork><![CDATA[
F--------------E
/ \
/ \
/ \
A D
\ /
\ /
\ /
B--------------C
]]></artwork>
</figure>
<figure anchor="gmlPoly">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
entity="pres:hexagon@example.com">
<tuple id="polygon-pos">
<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.111 -73.322</gml:pos> <!--B-->
<gml:pos>43.111 -73.222</gml:pos> <!--C-->
<gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--E-->
<gml:pos>43.411 -73.322</gml:pos> <!--F-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
<gp:usage-rules/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
<t>In addition to the form shown in <xref target="gmlPoly"/> 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 <xref target="gmlCompactPoly"/>. Both forms are permitted.
</t>
<t>
<figure anchor="gmlCompactPoly">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
entity="pres:hexagon@example.com">
<tuple id="polygon-poslist">
<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.111 -73.322
43.111 -73.222 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/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
</t>
</section>
<section title="Circle">
<t>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.</t>
<figure anchor="circle">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:circle@example.com">
<tuple id="circle">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<method>OTDOA</method>
</gp:geopriv>
</status>
</tuple>
</presence>
]]></artwork>
</figure>
</section>
<section title="Ellipse">
<t> 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.</t>
<figure anchor="ellipse">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:Ellipse@somecell.example.com">
<tuple id="ellipse">
<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/>
<method>Device-Assisted_A-GPS</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
<t>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. </t>
</section>
<section title="Arc Band">
<t> 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. </t>
<t> 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 <xref target="arcbanddiagram"/>. </t>
<figure anchor="arcbanddiagram">
<artwork><![CDATA[
N ^ ,.__
| a(s) / `-.
| 20 / `-.
|--. / `.
| `/ \
| /__ \
| . `-. \
| . `. \
|. \ \ .
---c-- a(o) -- | | -->
|. / 120 ' | E
| . / '
| . / ;
.,' /
r(i)`. /
(3594m) `. /
`. ,'
`. ,'
r(o)`'
(4148m)
]]></artwork>
</figure>
<t>The resulting PIDF-LO is shown in <xref target="arcband"/>.</t>
<figure anchor="arcband">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:paul@somecell.example.com">
<tuple id="arcband">
<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/>
<method>TA-NMR</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
<t> 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. </t>
</section>
<section title="Sphere">
<t>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. <xref target="sphere"/> shows the sphere shape, which is identical to the circle example,
except for the addition of an altitude in the provided coordinates. </t>
<figure anchor="sphere">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:circle@example.com">
<tuple id="sphere">
<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:usage-rules/>
<method>Device-Based_A-GPS</method>
</gp:geopriv>
</status>
</tuple>
</presence>
]]></artwork>
</figure>
</section>
<section title="Ellipsoid">
<t>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. </t>
<figure anchor="ellipsoiddiagram">
<artwork><![CDATA[
\
_.-\""""^"""""-._
.' \ | `.
/ v m \
| \ | |
| -c ----M---->|
| |
\ /
`._ _.'
`-...........-'
]]></artwork>
</figure>
<t> A PIDF-LO containing an ellipsoid appears as shown in <xref target="ellipsoid"/>. </t>
<figure anchor="ellipsoid">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:somone@gpsreceiver.example.com">
<tuple id="ellipsoid">
<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/>
<method>Hybrid_A-GPS</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
</section>
<section title="Prism">
<t> 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. </t>
<t>For example, looking at the cube in <xref target="prismdiagram"/>. 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. </t>
<figure anchor="prismdiagram">
<artwork><![CDATA[
G-----F
/| /|
/ | / |
H--+--E |
| C--|--B
| / | /
|/ |/
D-----A
]]></artwork>
</figure>
<t>The resulting PIDF-LO is shown in <xref target="prism"/>.</t>
<figure anchor="prism">
<artwork><![CDATA[
<?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="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:mike@someprism.example.com">
<tuple id="prism">
<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/>
<method>Wiremap</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t> 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. </t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> This document does not introduce any IANA considerations. </t>
</section>
<section anchor="ack" title="Acknowledgments">
<t> 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. </t>
<t>Thanks to Karen Navas for pointing out some emissions in the examples.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;&RFC4119;&RFC4479;
<reference anchor="GeoShape">
<front>
<title abbrev="Geo-Shape">GML 3.1.1 PIDF-LO Shape Application Schema for use by the
Internet Engineering Task Force (IETF)</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
</author>
<author initials="C." surname="Reed" fullname="Carl Reed, PhD.">
<organization>Open Geospatial Consortium Inc.</organization>
</author>
<date month="April" day="10" year="2007"/>
</front>
<seriesInfo name="Candidate OpenGIS Implementation Specification"
value="06-142r1, Version: 1.0"/>
</reference>
&I-D.ietf-geopriv-revised-civic-lo;
</references>
<references title="Informative References">
&RFC4776;
&RFC3693;
<reference
anchor="3GPP-TS-23_032">
<front>
<title abbrev="">3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; Technical
Specification Group Code Network; Universal Geographic Area Description (GAD) </title>
<author>
<organization/>
</author>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:50:03 |