GEOPRIV M. Thomson
Internet-Draft Microsoft
Intended status: Standards Track B. Rosen
Expires: September 20, 2013 Neustar
D. Stanley
Aruba Networks
G. Bajko
Nokia
A. Thomson
Cisco Systems, Inc.
March 19, 2013
Relative Location Representation
draft-ietf-geopriv-relative-location-04.txt
Abstract
This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow
display of the map with the reference point and the relative offset.
Also included in this document is a Type/Length/Value (TLV)
representation of the relative location for use in other protocols
that use TLVs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 20, 2013.
Thomson, et al. Expires September 20, 2013 [Page 1]
Internet-Draft Relative Location March 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Relative Coordinate System . . . . . . . . . . . . . . . 6
4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7
4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 8
4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 8
4.6. Relative Location Restrictions . . . . . . . . . . . . . 8
4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 8
4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 9
4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 10
4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 11
4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 13
4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 15
4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 17
4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 17
4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 17
4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 17
4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 17
4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 18
4.11.2. Map Coordinate Reference System . . . . . . . . . . 18
4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 20
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 21
5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 22
5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 23
6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 24
Thomson, et al. Expires September 20, 2013 [Page 2]
Internet-Draft Relative Location March 2013
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. Relative Location Registry . . . . . . . . . . . . . . . 27
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 28
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 29
8.4. CRS public identifier registration . . . . . . . . . . . 30
8.5. CAtype Registration . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
This document describes a format for the expression of relative
location information.
A relative location is formed of a reference location, plus a
relative offset from that reference location. The reference location
can be represented in either civic or geodetic form. The reference
location can also have dynamic components such as velocity. The
relative offset is specified in meters using a Cartesian coordinate
system.
In addition to the relative location, an optional URI can be provided
to a document that contains a map, floorplan or illustration.
Applications could use this information to display the relative
location. Additional fields allow the map to be oriented and scaled
correctly.
Two formats are included: an XML form that is intended for use in
PIDF-LO [RFC4119] and a TLV format for use in other protocols such as
those that already convey binary representation of location
information defined in [RFC4776].
2. Conventions used in this document
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 [RFC2119].
3. Overview
This document describes an extension to PIDF-LO [RFC4119] as updated
by [RFC5139] and [RFC5491], to allow the expression of a location as
an offset relative to a reference.
Thomson, et al. Expires September 20, 2013 [Page 3]
Internet-Draft Relative Location March 2013
This extension effectively allows the creator of a location object to
include two location values plus an offset. The "baseline" location
that is given outside of the <relative-location> element is what will
be visible to a client that does not understand that extension (i.e.,
one that ignores the <relative-location> element). A client that
does understand this extension will interpret the location within the
relative element as a refinement of the baseline location, which
gives the reference location for the relative offset.
Creators of location objects with relative location thus have a
choice of how much information to put into the "baseline" location
and how much to put into the "reference" location. For example, all
location information could be put inside the <relative-location>
element, so that clients that do not understand relative location
would receive no location information at all. Alternatively, the
baseline location value could be precise enough to specify a building
that contains the relative location, and the reference location could
specify a point within the building from which the offset is
measured.
The baseline location SHOULD be general enough to describe both the
reference location and the relative location (reference plus offset).
In particular, while it is possible to put all location information
into the "reference" location (leaving an universally broad
"baseline"), location objects SHOULD NOT have all location
information in the baseline location. Doing this would cause clients
that do not understand relative location to incorrectly interpret the
baseline location (i.e., the reference point) as the actual, precise
location of the client.
Both the baseline and the reference location are defined either as a
geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If
the baseline location was expressed as a geodetic location, the
reference MUST be geodetic. If the baseline location was expressed
as a civic address, the reference MUST be a civic.
Baseline and reference locations MAY also include dynamic location
information [RFC5962].
The relative location can be expressed using a point (2- or
3-dimensional), or a shape that includes uncertainty: circle, sphere,
ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of
these shapes can be found in [RFC5491].
Optionally, a reference to a 'map' document can be provided. The
reference is a URI. The document could be an image or dataset that
represents a map, floorplan or other form. The type of document the
URI points to is described as a MIME media type. Metadata in the
Thomson, et al. Expires September 20, 2013 [Page 4]
Internet-Draft Relative Location March 2013
relative location can include the location of the reference point in
the map as well as an orientation (angle from North) and scale to
align the document Co-ordinate Reference System (CRS) with the WGS84
[WGS84] CRS. The document is assumed to be useable by the
application receiving the PIDF with the relative location to locate
the reference point in the map. This document does not describe any
mechanisms for displaying or manipulating the document other than
providing the reference location, orientation and scale.
As an example, consider a relative location expressed as a point,
relative to a civic location:
<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:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:relative@example.com">
<dm:device id="relative1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:INT N="Door" R="A">Front</ca:INT>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos>
</gml:Point>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
Thomson, et al. Expires September 20, 2013 [Page 5]
Internet-Draft Relative Location March 2013
<rel:map>
<rel:url type="image/png">
http://example.com/location/map.png
</rel:url>
<rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale>
</rel:map>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
4. Relative Location
Relative location is a shape (point, circle, ellipse...). The shape
is defined with a CRS that has a datum defined as the reference
(which appears as a civic address or geodetic location in the tuple),
and the shape coordinates as meter offsets North/East of the datum
measured in meters (with an optional Z offset relative to datum
altitude). An optional angle allows the reference CRS be to rotated
with respect to North.
4.1. Relative Coordinate System
The relative coordinate reference system uses a coordinate system
with two or three axes.
The baseline and reference locations are used to define a relative
datum. The reference location defines the origin of the coordinate
system. The centroid of the reference location is used when the
reference location contains any uncertainty.
The axes in this coordinate system are originally oriented based on
the directions of East, North and Up from the reference location: the
first (x) axis increases to the East, the second (y) axis points
North, and the optional third (z) axis points Up. All axes of the
coordinate system use meters as a basic unit.
Any coordinates in the relative shapes use the described Cartesian
coordinate system. In the XML form, this uses a URN of
"urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and
"urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes.
The binary form uses different shape type identifiers for 2D and 3D
shapes.
Thomson, et al. Expires September 20, 2013 [Page 6]
Internet-Draft Relative Location March 2013
Dynamic location information [RFC5962] in the baseline or reference
location alters relative coordinate system. The resulting Cartesian
coordinate system axes are rotated so that the 'y' axis is oriented
along the direction described by the <orientation> element. The
coordinate system also moves as described by the <speed> and
<heading> elements.
4.2. Placement of XML Elements
The baseline of the reference location is represented as <location-
info> like a normal PIDF-LO. Relative location adds a new <relative-
location> element to <location-info>. Within <relative-location>,
<reference> and <offset> elements are described. Within <offset> are
the shape elements described below. This document extends PIDF-LO as
described in [RFC6848].
4.3. Binary Format
This document describes a way to encode the relative location in a
binary TLV form for use in other protocols that use TLVs to represent
location.
A type-length-value encoding is used.
+------+------+------+------+------+------+------+
| Type |Length| Value ...
+------+------+------+------+------+------+
| X | N | Value ...
+------+------+------+------+------+------+------+
Figure 1: TLV-tuple format
Type field (X) is defined as a single byte. The type codes used are
registered an IANA-managed 'RLtypes' registry defined by this
document, and restricted to not include the values defined by the
CAtypes registry. This restriction permits a location reference and
offset to be coded with unique TLVs.
The Length field (N) is defined as an unsigned integer that is one
byte in length. This field can encode values from 0 to 255. The
length field describes the number of bytes in the Value. Length does
not count the bytes used for the Type or Length.
The Value field is defined separately for each type.
Each element of the relative location has a unique TLV assignment. A
relative location encoded in TLV would have the baseline location
TLVs and a reference location TLV which contains within it the
Thomson, et al. Expires September 20, 2013 [Page 7]
Internet-Draft Relative Location March 2013
reference refinement TLVs. The reference TLVs are followed by the
relative offset, and optional map TLDs described in this document.
4.4. Distances and Angles
All distance measures used in shapes are expressed in meters.
All orientation angles used in shapes are expressed in degrees.
Orientation angles are measured from WGS84 Northing to Easting with
zero at Northing. Orientation angles in the relative coordinate
system start from the second coordinate axis (y or Northing) and
increase toward the first axis (x or Easting).
4.5. Value Encoding
The binary form uses single-precision floating point values IEEE 754
[IEEE.754] to represent coordinates, distance and angle measures.
Single precision values are 32-bit values with a sign bit, 8 exponent
bits and 23 fractional bits.
Binary-encoded coordinate values are considered to be a single value
without uncertainty. When encoding a value that cannot be exactly
represented, the best approximation MUST be selected according to
[Clinger1990].
4.6. Relative Location Restrictions
More than one relative shape MUST NOT be included in either a PIDF-LO
or TLV encoding of location for a given reference point.
Any error in the reference point transfers to the location described
by the relative location. Any errors arising from an implementation
not supporting or understanding elements of the reference point
directly increases the error (or uncertainty) in the resulting
location.
4.7. Baseline TLVs
Baseline locations are described using the formats defined in
[RFC4776] or [RFC6225].
4.8. Reference TLV
When a reference is encoded in binary form, the baseline and
reference locations are combined in a reference TLV. This TLV
contains civic address TLVs (if the baseline was a civic) or geo TLVs
(if the baseline was a geo).
Thomson, et al. Expires September 20, 2013 [Page 8]
Internet-Draft Relative Location March 2013
+------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
Reference TLV
4.9. Shapes
Shape data is used to represent regions of uncertainty for the
reference and relative locations. Shape data in the reference
location uses a [WGS84] CRS. Shape data in the relative location
uses a relative CRS.
The XML form for shapes uses Geography Markup Language (GML)
[OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference
locations use the CRS URNs specified in [RFC5491]; relative locations
use either a 2D CRS (urn:ietf:params:geopriv:relative:2d), or a 3D
(urn:ietf:params:geopriv:relative:3d), depending on the shape type.
The binary form of each shape uses a different shape type for 2d and
3d shapes.
Nine shape type codes are defined.
4.9.1. Point
A point "shape" describes a single point with unknown uncertainty.
It consists of a single set of coordinates.
In a two-dimensional CRS, the coordinate includes two values; in a
three-dimensional CRS, the coordinate includes three values.
4.9.1.1. XML encoding
A point is represented in GML using the following template:
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point>
GML Point Template
Where "$CRS-URN$" is replaced by a
urn:ietf:params:geopriv:relative:2d or
urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted
if the CRS is two-dimensional.
Thomson, et al. Expires September 20, 2013 [Page 9]
Internet-Draft Relative Location March 2013
4.9.1.2. TLV encoding
The point shape is introduced by a TLV of 113 for a 2D point and 114
for a 3D point.
+------+------+
| 113/4|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Point Encoding
4.9.2. Circle or Sphere Shape
A circle or sphere describes a single point with a single uncertainty
value in meters.
In a two-dimensional CRS, the coordinate includes two values and the
resulting shape forms a circle. In a three-dimensional CRS, the
coordinate includes three values and the resulting shape forms a
sphere.
4.9.2.1. XML encoding
A circle is represented in and converted from GML using the following
template:
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Circle>
GML Circle Template
A sphere is represented in and converted from GML using the following
template:
Thomson, et al. Expires September 20, 2013 [Page 10]
Internet-Draft Relative Location March 2013
<gs:Sphere xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Sphere>
GML Sphere Template
4.9.2.2. TLV encoding
A circular shape is introduced by a type code of 115. A spherical
shape is introduced by a type code of 116.
+------+------+
| 115/6|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
| Radius |
+------+------+------+------+
Circle or Sphere Encoding
4.9.3. Ellipse or Ellipsoid Shape
A ellipse or ellipsoid describes a point with an elliptical or
ellipsoidal uncertainty region.
In a two-dimensional CRS, the coordinate includes two values, plus a
semi-major axis, a semi-minor axis, a semi-major axis orientation
(clockwise from North). In a three-dimensional CRS, the coordinate
includes three values and in addition to the two-dimensional values,
an altitude uncertainty (semi-vertical) is added.
4.9.3.1. XML encoding
An ellipse is represented in and converted from GML using the
following template:
Thomson, et al. Expires September 20, 2013 [Page 11]
Internet-Draft Relative Location March 2013
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipse>
GML Ellipse Template
An ellipsoid is represented in and converted from GML using the
following template:
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipsoid>
GML Ellipsoid Template
4.9.3.2. TLV encoding
An ellipse is introduced by a type code of 117 and an ellipsoid is
introduced by a type code of 118.
+------+------+
| 117/8|Length|
+------+------+------+------+
Thomson, et al. Expires September 20, 2013 [Page 12]
Internet-Draft Relative Location March 2013
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+
Ellipse or Ellipsoid Encoding
4.9.4. Polygon or Prism Shape
A polygon or prism include a number of points that describe the outer
boundary of an uncertainty region. A prism also includes an altitude
for each point and prism height.
At least 3 points MUST be included in a polygon. In order to
interoperate with existing systems, an encoding SHOULD include 15 or
fewer points, unless the recipient is known to support larger
numbers.
4.9.4.1. XML Encoding
A polygon is represented in and converted from GML using the
following template:
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
GML Polygon Template
Thomson, et al. Expires September 20, 2013 [Page 13]
Internet-Draft Relative Location March 2013
Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains two or three
coordinate values.
Note that the first point is repeated at the end of the sequence of
coordinates and no explicit count of the number of points is
provided.
A GML polygon that includes altitude cannot be represented completely
in binary. When converting to the binary representation, a two
dimensional CRS is used and altitude is removed from each coordinate.
A prism is represented in and converted from GML using the following
template:
<gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$
$Coordinate2-1$ ... ...
...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$
</gs:height>
</gs:Prism>
GML Prism Template
Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains three coordinate
values.
4.9.4.2. TLV Encoding
Thomson, et al. Expires September 20, 2013 [Page 14]
Internet-Draft Relative Location March 2013
A polygon containing 2D points uses a type code of 119. A polygon
with 3D points uses a type code of 120. A prism uses a type code of
121. The number of points can be inferred from the length of the
TLV.
+------+------+
|119-21|Length|
+------+------+------+------+
| (3D-only) Height |
+------+------+------+------+
| Coordinate1-1 |
+------+------+------+------+
| Coordinate1-2 |
+------+------+------+------+
| (3D-only) Coordinate1-3 |
+------+------+------+------+
| Coordinate2-1 |
+------+------+------+------+
...
+------+------+------+------+
| CoordinateN-1 |
+------+------+------+------+
| CoordinateN-2 |
+------+------+------+------+
| (3D-only) CoordinateN-3 |
+------+------+------+------+
Polygon or Prism Encoding
Note that unlike the polygon representation in GML, the first and
last points are not the same point in the TLV representation. The
duplicated point is removed from the binary form.
4.9.5. Arc-Band Shape
A arc-band describes a region constrained by a range of angles and
distances from a predetermined point. This shape can only be
provided for a two-dimensional CRS.
Distance and angular measures are defined in meters and degrees
respectively. Both are encoded as single precision floating point
values.
Thomson, et al. Expires September 20, 2013 [Page 15]
Internet-Draft Relative Location March 2013
4.9.5.1. XML encoding
An arc-band is represented in and converted from GML using the
following template:
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$
</gs:openingAngle>
</gs:ArcBand>
GML Arc-Band Template
4.9.5.2. TLV Encoding
An arc-band is introduced by a type code of 122.
+------+------+
| 122 |Length|
+------+------+------+------+
| Coordinate |
+------+------+------+------+
| Coordinate |
+------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+
Arc-Band Encoding
Thomson, et al. Expires September 20, 2013 [Page 16]
Internet-Draft Relative Location March 2013
4.10. Dynamic Location TLVs
Dynamic location elements use the definitions in [RFC5962].
4.10.1. Orientation
The orientation of the target is described using one or two angles.
+------+------+
| 123 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Dynamic Orientation TLVs
4.10.2. Speed
The speed of the target is a scalar value in meters per second.
+------+------+
| 124 |Length|
+------+------+------+------+
| Speed |
+------+------+------+------+
Dynamic Speed TLVs
4.10.3. Heading
The heading, or direction of travel, is described using one or two
angles.
+------+------+
| 125 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Dynamic Heading TLVs
4.11. Secondary Map Metadata
Thomson, et al. Expires September 20, 2013 [Page 17]
Internet-Draft Relative Location March 2013
The optional "map" URL can be used to provide a user of relative
location with a visual reference for the location information. This
document does not describe how the recipient uses the map nor how it
locates the reference or offset within the map. Maps can be simple
images, vector files, 2-D or 3-D geospatial databases, or any other
form of representation understood by both the sender and recipient.
4.11.1. Map URL
In XML, the map is a <map> element defined within <relative-location>
and contains the URL. The URL is encoded as a UTF-8 encoded string.
An "http:" or "https:" URL MUST be used unless the entity creating
the PIDF-LO is able to ensure that authorized recipients of this data
are able to use other URI schemes. A "type" attribute MUST be
present and specifies the kind of map the URL points to. Map types
are specified as mime media types as recorded in the IANA Media Types
registry. For example <map type="image/png">https://www.example.com/
floorplans/123South/floor-2</map>. In binary, the map type is a
separate TLV from the map URL:
+------+------+------+------+------+-- --+------+
| 126 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+
| 127 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+
Map URL TLVs
4.11.2. Map Coordinate Reference System
The CRS used by the map depends on the type of map. For example, a
map described by a 3-D geometric model of the building may contain a
complete CRS description in it. For some kinds of maps, typically
described as images, the CRS used within the map must define the
following:
o The CRS origin
o The CRS axes used and their orientation
o The unit of measure used
This document provides elements that allow for a mapping between the
local coordinate reference system used for the relative location and
the coordinate reference system used for the map where they are not
the same.
Thomson, et al. Expires September 20, 2013 [Page 18]
Internet-Draft Relative Location March 2013
4.11.2.1. Map Reference Point Offset
This optional element identifies the coordinates of the reference
point as it appears in the map. This value is measured in a map-type
dependent manner, using the coordinate system of the map.
For image maps, coordinates start from the upper left corner and
coordinates are first counted by column with positive values to the
right; then rows are counted with positive values toward the bottom
of the image. For such an image, the first item is columns, the
second rows and any third value applies to any third dimension used
in the image coordinate space.
The <offset> element contains 2 (or 3) coordinates similar to a GML
"pos", For example:
<offset> 2670.0 1124.0 1022.0</offset>
Map Reference Point Example XML
+------+------+
| 128 |Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Map Reference Point Coordinates TLV
If omitted, a value containing all zeros is assumed. If the
coordinates provided contain fewer values than are needed, the first
value from the set is applied in place of any missing values.
4.11.2.2. Map Orientation
The map orientation includes the orientation of the map direction in
relation to the Earth. Map orientation is expressed relative to the
orientation of the relative coordinate system. This means that map
orientation with respect to WGS84 North is the sum of the orientation
field, plus any orientation included in a dynamic portion of the
reference location. Both values default to zero if no value is
specified.
This type uses a single precision floating point value of degrees
relative to North.
Thomson, et al. Expires September 20, 2013 [Page 19]
Internet-Draft Relative Location March 2013
In XML, the <orientation> element contains a single floating point
value, example <orientation>67.00</orientation>. In TLV form:
+------+------+------+------+------+------+
| 129 |Length| Angle |
+------+------+------+------+------+------+
Map Orientation TLV
4.11.2.3. Map Scale
The optional map scale describes the relationship between the units
of measure used in the map, relative to the meters unit used in the
relative coordinate system.
This type uses a sequence of IEEE 754 [IEEE.754] single precision
floating point values to represent scale as a sequence of numeric
values. The units of these values are dependent on the type of map,
and could for example be pixels per meter for an image.
A scaling factor is provided for each axis in the coordinate system.
For a two-dimensional coordinate system, two values are included to
allow for different scaling along the x and y axes independently.
For a three-dimensional coordinate system, three values are specified
for the x, y and z axes. Decoders can determine the number of
scaling factors by examining the length field.
Alternatively, a single scaling value MAY be used to apply the same
scaling factor to all coordinate components.
Images that use a rows/columns coordinate system often use a left-
handed coordinate system. A negative value for the y/rows-axis
scaling value can be used to account for any change in direction
between the y-axis used in the relative coordinate system and the
rows axis of the image coordinate system.
In XML, the <scale> element may contain the single scale value, or
may contain 2 (or 3) values similar to a GML "pos" with separate
scale values. In TLV form:
+------+------+------+------+------+
| 130 |Length| Scales ...
+------+------+------+------+------+
Map Scale TLV
4.11.3. Map Example
Thomson, et al. Expires September 20, 2013 [Page 20]
Internet-Draft Relative Location March 2013
An example of expressing a map is:
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
Map Example
5. Examples
5.1. Civic PIDF with Polygon Offset
<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:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
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">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:INT N="Building">A</ca:INT>
<ca:INT N="Level">I</ca:INT>
<ca:INT N="Suite">113</ca:INT>
<ca:INT N="Door" R="A">Front</ca:INT>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
Thomson, et al. Expires September 20, 2013 [Page 21]
Internet-Draft Relative Location March 2013
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
<gml:pos>431.0 -733.0</gml:pos> <!--F-->
<gml:pos>431.0 -732.0</gml:pos> <!--E-->
<gml:pos>433.0 -731.0</gml:pos> <!--D-->
<gml:pos>434.0 -732.0</gml:pos> <!--C-->
<gml:pos>434.0 -733.0</gml:pos> <!--B-->
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
5.2. Geo PIDF with Circle Offset
<?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:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0
</gml:radius>
</gs:Circle>
<rel:relative-location>
<rel:reference>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
Thomson, et al. Expires September 20, 2013 [Page 22]
Internet-Draft Relative Location March 2013
</gml:Point>
</rel:reference>
<rel:offset>
<gml:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gml:radius>
</gml:Circle>
</rel:offset>
<rel:map>
<rel:urltype="image/png">
https://www.example.com/flrpln/123South/flr-2
</rel:url>
<rel:offset> 2670.0 1124.0 1022.0</rel:offset>
<rel:orientation>67.00</rel:orientation>
<rel:scale>10</rel:scale>
</rel:map>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5.3. Civic TLV with Point Offset
+--------+-------------------------------------------------+
| Type | Value |
+--------+-------------------------------------------------+
| 0 | en |
| | |
| 1 | IL |
| | |
| 3 | Chicago |
| | |
| 34 | Wacker |
| | |
| 18 | Drive |
Thomson, et al. Expires September 20, 2013 [Page 23]
Internet-Draft Relative Location March 2013
| | |
| 19 | 3400 |
| | |
| 112 | Reference |
| | |
| 25 | Building A |
| | |
| 27 | Floor 6 |
| | |
| 26 | Suite 213 |
| | |
| 28 | Reception Area |
| | |
| 115 | 100 70 |
| | |
| 126 | image/png |
| | |
| 127 | http://maps.example.com/3400Wacker/A6 |
| | |
| 128 | 0.0 4120.0 |
| | |
| 129 | 113.0 |
| | |
| 130 | 10.6 |
+--------+-------------------------------------------------+
6. Schema Definition
<?xml version="1.0"?>
<xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL
'http://ietf.org/rfc/rfcXXXX.txt' with the URL of published
document and remove this note.]] -->
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:relative">
Relative Location for PIDF-LO
</xs:appinfo>
<xs:documentation source="http://ietf.org/rfc/rfcXXXX.txt">
Thomson, et al. Expires September 20, 2013 [Page 24]
Internet-Draft Relative Location March 2013
This schema defines a location representation that allows for
the description of locations that are relative to another.
An optional map reference is also defined.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="relative-location" type="rel:relativeType"/>
<xs:complexType name="relativeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="reference" type="rel:referenceType"/>
<xs:element name="offset" type="rel:offsetType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="referenceType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="offsetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="gml:_Geometry"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="map" type="rel:mapType"/>
Thomson, et al. Expires September 20, 2013 [Page 25]
Internet-Draft Relative Location March 2013
<xs:complexType name="mapType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="url" type="rel:mapUrlType"/>
<xs:element name="offset" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="orientation" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="scale" type="rel:doubleList"
minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="mapUrlType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="type" type="rel:mimeType"
default="application/octet-stream"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="mimeType">
<xs:restriction base="xs:token">
<xs:pattern value="[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+
/[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+([\t ]*;([\t ])*[!#$%&
'\*\+\-\.\dA-Z^_`a-z\|~]+=([!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+|
"([!#-\[\]-~]|[\t ]*|\\[\t !-~])*"))*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/>
</xs:simpleType>
</xs:schema>
xml schema relative-location
7. Security Considerations
This document describes a data format. To a large extent, security
properties of this depend on how this data is used.
Thomson, et al. Expires September 20, 2013 [Page 26]
Internet-Draft Relative Location March 2013
Privacy for location data is typically important. Adding relative
location may increase the precision of the location, but does not
otherwise alter its privacy considerations, which are discussed in
[RFC4119]
The fractional bits in IEEE 754 [IEEE.754] floating point values can
be used as a covert channel. For values of either zero or infinity,
non-zero fraction bits could be used to convey information. If the
presence of covert channels is not desired then the fractional bits
MUST be set to zero. There is no need to represent NaN (not a
number) in this encoding.
8. IANA Considerations
8.1. Relative Location Registry
This document creates a new registry called 'Relative Location
Parameters'. As defined in [RFC5226], this registry operates under
"IETF Review" rules.
The content of this registry includes:
Relative Location Code: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the
element.
Reference to published specification: A stable reference to an RFC
which describes the value in sufficient detail so that
interoperability between independent implementations is possible.
Values requested to be assigned into this registry MUST NOT conflict
with values assigned in the CAtypes registry or vice versa, unless
the IANA considerations section for the new value explicitly
overrides this prohibition and the document defining the value
describes how conflicting TLV codes will be interpreted by
implementations.
The values defined are:
+--------+----------------------------------------+-----------+
| RLtype | description | Reference |
+--------+-------+--------------------------------+-----------+
| 111 | relative location reference | this RFC |
| 113 | relative location shape 2D point | this RFC |
| 114 | relative location shape 3D point | this RFC |
| 115 | relative location shape circular | this RFC |
| 116 | relative location shape spherical | this RFC |
Thomson, et al. Expires September 20, 2013 [Page 27]
Internet-Draft Relative Location March 2013
| 117 | relative location shape elliptical | this RFC |
| 118 | relative location shape ellipsoid | this RFC |
| 119 | relative location shape 2D polygon | this RFC |
| 120 | relative location shape 3D polygon | this RFC |
| 121 | relative location shape prism | this RFC |
| 122 | relative location shape arc-band | this RFC |
| 123 | relative location dynamic orientation | this RFC |
| 124 | relative location dynamic speed | this RFC |
| 125 | relative location dynamic heading | this RFC |
| 126 | relative location map type | this RFC |
| 127 | relative location map URI | this RFC |
| 128 | relative location map coordinates | this RFC |
| 129 | relative location map angle | this RFC |
| 130 | relative location map scale | this RFC |
+--------+-------+--------------------------------+-----------+
8.2. URN Sub-Namespace Registration
This document registers a new XML namespace, as per the guidelines in
[RFC3688]).
Thomson, et al. Expires September 20, 2013 [Page 28]
Internet-Draft Relative Location March 2013
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location</title>
</head>
<body>
<h1>Format for representing relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published
document and remove this note.]] -->
END
8.3. XML Schema Registration
This section registers an XML schema as per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net).
The XML for this schema is the entirety of Section 6
of this document.
Thomson, et al. Expires September 20, 2013 [Page 29]
Internet-Draft Relative Location March 2013
8.4. CRS public identifier registration
This section registers two public identifiers as per the procedures
in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location 2d CRS</title>
</head>
<body>
<h1>Identifier for a 2D CRS in relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published document
and remove this note.]] -->
END
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org)
Martin Thomson (martin.thomson@skype.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location 3d CRS</title>
</head>
Thomson, et al. Expires September 20, 2013 [Page 30]
Internet-Draft Relative Location March 2013
<body>
<h1>Identifier for a 3D CRS in relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published
document and remove this note.]] -->
END
8.5. CAtype Registration
This section adds a new entry to the CAtype registry defined by
[RFC6848].
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Local Name: REL
Description: Relative location from a reference point
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org).
Specification: RFCXXXX
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Type: A
9. Acknowledgements
This is the product of a design team on relative location. Besides
the authors, this team included: Marc Linsner, James Polk, and James
Winterbottom.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
Thomson, et al. Expires September 20, 2013 [Page 31]
Internet-Draft Relative Location March 2013
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", RFC 5962,
September 2010.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in the
Presence Information Data Format Location Object (PIDF-
LO)", RFC 6848, January 2013.
[OGC.GML-3.1.1]
Cox, S., Daisey, P., Lake, R., Portele, C., and A.
Whiteside, "Geographic information - Geography Markup
Language (GML)", OpenGIS 03-105r1, April 2004, <http://
portal.opengeospatial.org/files/?artifact_id=4700>.
[OGC.GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", OGC Best Practice 06-142r1, Version:
1.0, April 2007.
[IEEE.754]
IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", IEEE Standard 754-1985, January 2003.
[Clinger1990]
Thomson, et al. Expires September 20, 2013 [Page 32]
Internet-Draft Relative Location March 2013
Clinger, W., "How to Read Floating Point Numbers
Accurately", Proceedings of Conference on Programming
Language Design and Implementation pp. 92-101, 1990, <ftp:
//ftp.ccs.neu.edu/pub/people/will/howtoread.ps>.
10.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[WGS84] US National Imagery and Mapping Agency , ""Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition"", NIMA TR8350.2, January 2000.
Authors' Addresses
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
US
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net
Brian Rosen
Neustar
470 Conrad Dr
Mars, PA 16046
US
EMail: br@brianrosen.net
Dorothy Stanley
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
US
EMail: dstanley@arubanetworks.com
Thomson, et al. Expires September 20, 2013 [Page 33]
Internet-Draft Relative Location March 2013
Gabor Bajko
Nokia
323 Fairchild Drive
Mountain View, CA 94043
US
EMail: gabor.bajko@nokia.com
Allan Thomson
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
EMail: althomso@cisco.com
Thomson, et al. Expires September 20, 2013 [Page 34]
