GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Standards Track B. Rosen
Expires: August 30, 2010 Neustar
D. Stanley
Aruba Networks
G. Bajko
Nokia
A. Thomson
Cisco Systems, Inc.
February 26, 2010
Relative Location Representation
draft-thomson-geopriv-relative-location-00
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Thomson, et al. Expires August 30, 2010 [Page 1]
Internet-Draft Relative Location February 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2010.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Thomson, et al. Expires August 30, 2010 [Page 2]
Internet-Draft Relative Location February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Orientation of Relative Offset Coordinate Reference
System . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Shape Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Units of Measure . . . . . . . . . . . . . . . . . . . . . 9
6.2. Coordinates . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. On Uncertainty and Encoding . . . . . . . . . . . . . . . 10
7. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 10
7.1.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 10
7.2. Circle or Sphere Shape . . . . . . . . . . . . . . . . . . 11
7.2.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 11
7.2.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 12
7.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . . . 12
7.3.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 13
7.3.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 14
7.4. Polygon or Prism Shape . . . . . . . . . . . . . . . . . . 14
7.4.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . 15
7.4.2. Arc-Band Shape . . . . . . . . . . . . . . . . . . . . 17
8. Secondary Map Metadata . . . . . . . . . . . . . . . . . . . . 18
8.1. Map URL . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Map Coordinate Reference System . . . . . . . . . . . . . 19
8.2.1. Map Reference Point Offset . . . . . . . . . . . . . . 19
8.2.2. Map Orientation . . . . . . . . . . . . . . . . . . . 20
8.2.3. Map Scale . . . . . . . . . . . . . . . . . . . . . . 21
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 21
9.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23
9.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 24
10. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. Relative Location Registry . . . . . . . . . . . . . . . . 25
12.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:???? . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Thomson, et al. Expires August 30, 2010 [Page 3]
Internet-Draft Relative Location February 2010
1. Introduction
This document describes a format for the expression of relative
location information.
The location is given relative to a reference, which is expressed
with a civic or geodetic representation, with the relative offset as
described in this document. The offset is expressed in meters, and a
directional vector is either implied to be earth North/East or
supplied explicitly. Also defined is an optional URI to a document
that can contain a map/floorplan/illustration ('map') upon which the
relative location can be plotted as well as an optional angle, offset
and scale defining the Coordinate Reference System (CRS) of the map.
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].
Numeric values in this scheme are all represented using floating
point values [IEEE.754]. Single precision values are 32-bit values
with a sign bit, 8 exponent bits and 23 fractional bits. Double
precision values are 64-bit values with a sign bit, 11 exponent bits
and 52 fractional bits.
3. Overview
This document describes an update to PIDF-LO [RFC4119] as updated by
[RFC5139] and [RFC5491], to allow the expression of a location
relative to a reference. The reference is described by using
existing elements, and the offset is additional data to the tuple.
The reference point is defined either as a geodetic location
[OGC.GeoShape] or a civic address [RFC4776].
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
Thomson, et al. Expires August 30, 2010 [Page 4]
Internet-Draft Relative Location February 2010
represents a map, floorplan or other form. The type of document the
URI points to is described as a mime type. Metadata in the 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 CRS with the WGS-84 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:
Thomson, et al. Expires August 30, 2010 [Page 5]
Internet-Draft Relative Location February 2010
AU
NSW
Wollongong
North Wollongong
Flinders
Street
123
Front
100 50
GPS
mac:1234567890ab
2007-06-22T20:57:29Z
4. 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.
Thomson, et al. Expires August 30, 2010 [Page 6]
Internet-Draft Relative Location February 2010
+------+------+------+------+------+------+------+------+
| Type | Length | Value ...
+------+------+------+------+------+------+------+------+
| X | N | Value label ...
+------+------+------+------+------+------+------+------+
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 two
bytes in length. This field can encode values from 0 to 65535. The
length field describes the number of bytes in the Value. Length does
not count the bytes used for the Type or Length. Note that the
length field of a TLVs using the CAtypes registry (such as those
defined in [RFC5139] are one byte. Since the type codes defined here
are restricted to be different from the CAtypes, the difference in
the length field can be accommodated.
The value field is defined explicitly for each shape in this
document.
5. 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 civicLoc or gml-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.
A 2-dimensional reference MUST have a 2-dimensional relative offset,
and a 3-dimensional reference MUST have a 3-dimensional offset. This
makes the selection of 2-D or 3-D CRS defined by the reference.
The offset is contained in a element extending the
element of a PIDF-LO. Within the
element contains the shape encoded as described in Section 6.
Ed. Note, the authors are not unanimous in defining the reference
location as the civic or geo location-info currently defined in a
PIDF-LO with the additional element. Some authors
point out that an implementation that encounters the but does not implement it would ignore it, and treat the
reference as the actual location of the target, which is incorrect,
especially considering that the offset could potentially be very
large, and thus the actual location could differ from the reference
by a considerable distance. The remaining authors believe that such
uses are very rare, the document should contain a warning about the
possibility of error, and that the very best possible location that
could be provided in the case that the implementation does not
implement this extension is the reference. They believe that the
reference is a better location than no location. If the work group
decides that the reference should not be understood as the location
if an implementation does not understand , then this
document would define as a and
within that, define a element containing a gml or
civicLoc element plus an element. An implementation
encountering the would ignore the entire element,
including the reference that is within it.
The individual elements of the relative location have unique TLV
assignments. A relative location encoded in TLV would have the
location reference TLDs followed by the relative offset, and optional
map TLDs described in this document.
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.
5.1. Orientation of Relative Offset Coordinate Reference System
The relative location element may contain an optional angle relative
to North that defines the CRS of the offset. The offset CRS scale is
always meters, and the datum is the reference. The angle is encoded
as a single precision floating point degrees, with 0.0 representing
North. In xml, the angle is contained in an element,
example 50.0. In TLV encoding:
+------+------+------+------+------+------+------+
| 115 | Length | Angle |
+------+------+------+------+------+------+------+
Relative Offset Orientation TLV
Thomson, et al. Expires August 30, 2010 [Page 8]
Internet-Draft Relative Location February 2010
6. Shape Encoding
Shape data is used to represent regions of uncertainty in the
relative CRS.
The description of each shape type includes a description of how that
type is encoded in Geography Markup Language (GML) [OGC.GML-3.1.1],
consistent with the rules in [RFC5491], but with a relative CRS. The
CRS is identified by a distinguished urn --tbd-- defined by this
document.
6.1. Units of Measure
All distance measures used in shapes are expressed in meters using
single precision floating point values.
All orientation angles used in shapes are expressed in degrees using
single precision floating point values. 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).
6.2. Coordinates
Coordinates are a sequence of numeric values. These are encoded as a
sequence of double precision floating point numbers.
Coordinates are represented using a single precision floating point
value as described in IEEE 754 [IEEE.754].
Every CRS MUST define how many values are present in each set of
coordinates, the axes that each value applies to, the order of axes,
and the units that are used for each axis.
For the two-dimensional CRS, coordinates are made of two values. The
first value corresponds to latitude (Easting). The second value
corresponds to longitude (Northing). Both axis are rotated relative
to North by the ro-angle, if present.
For the three-dimensional CRS, coordinates are made of three values,
the first two of which are the same as for the two-dimensional CRS.
The third value corresponds to the altitude above the plane of the
horizontal at the reference location and is measured in meters.
Thomson, et al. Expires August 30, 2010 [Page 9]
Internet-Draft Relative Location February 2010
6.3. On Uncertainty and Encoding
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 is chosen according to
[Clinger1990].
7. Shapes
Nine shape type codes are defined.
7.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.
7.1.1. XML encoding
A point is represented in GML using the following template:
$Coordinate-1 $Coordinate-2$ $Coordinate-3$
GML Point Template
Where "$CRS-URN$" is replaced by a URN identifying the CRS and
"$Coordinate-3$" is omitted if the CRS is two-dimensional.
7.1.2. TLV encoding
The point shape is introduced by a TLV of 116 for a 2D point and 117
for a 3D point.
+------+-------------+
| 116/7| Length |
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Thomson, et al. Expires August 30, 2010 [Page 10]
Internet-Draft Relative Location February 2010
Point Encoding
7.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. The uncertainty radius is specified as a single precision
floating point value (32 bits: 1 sign bit, 8 exponent bits, 23
fractional bits in binary).
The circle size is defined as a radius in meters encoded as single
precision floating point value
7.2.1. XML encoding
A circle is represented in and converted from GML using the following
template:
$Coordinate-1 $Coordinate-2$
$Radius$
GML Circle Template
A sphere is represented in and converted from GML using the following
template:
$Coordinate-1 $Coordinate-2$ $Coordinate-3$
$Radius$
GML Sphere Template
Thomson, et al. Expires August 30, 2010 [Page 11]
Internet-Draft Relative Location February 2010
7.2.2. TLV encoding
A circular shape is introduced by a type code of 120. A spherical
shape is introduced by a type code of 121.
+------+-------------+
| 120/1| Length |
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
| Radius |
+------+------+------+------+
Circle or Sphere Encoding
7.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.
Distance and angular measures are defined in meters and degrees
respectively. Both are encoded as single precision floating point
values.
Thomson, et al. Expires August 30, 2010 [Page 12]
Internet-Draft Relative Location February 2010
7.3.1. XML encoding
An ellipse is represented in and converted from GML using the
following template:
$Coordinate-1 $Coordinate-2$
$Semi-Major$
$Semi-Minor$
$Orientation$
GML Ellipse Template
An ellipsoid is represented in and converted from GML using the
following template:
$Coordinate-1 $Coordinate-2$ $Coordinate-3$
$Semi-Major$
$Semi-Minor$
$Semi-Vertical$
$Orientation$
GML Ellipsoid Template
Thomson, et al. Expires August 30, 2010 [Page 13]
Internet-Draft Relative Location February 2010
7.3.2. TLV encoding
An ellipse is introduced by a type code of 118 and an ellipsoid is
introduced by a type code of 119.
+------+-------------+
| 118/9| Length |
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+
Ellipse or Ellipsoid Encoding
7.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
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.
The height of the prism is encoded as a single precision floating
point value.
Thomson, et al. Expires August 30, 2010 [Page 14]
Internet-Draft Relative Location February 2010
7.4.1. XML Encoding
A polygon is represented in and converted from GML using the
following template:
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
GML Polygon Template
Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains two 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.
Thomson, et al. Expires August 30, 2010 [Page 15]
Internet-Draft Relative Location February 2010
7.4.1.1. XML encoding
A prism is represented in and converted from GML using the following
template:
$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$
$Height$
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.
7.4.1.2. TLV Encoding
A polygon is introduced with a type code of 120. A prism is
introduced with a type code of 121.
Thomson, et al. Expires August 30, 2010 [Page 16]
Internet-Draft Relative Location February 2010
+------+-------------+
| 120/1| Length |
+------+------+------+------+------+------+
| Count | (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 required to be the same in the TLV
representation. an explicit count of the number of points is provided
in 'Count'.
7.4.2. 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 August 30, 2010 [Page 17]
Internet-Draft Relative Location February 2010
7.4.2.1. XML encoding
An arc-band is represented in and converted from GML using the
following template:
$Coordinate-1 $Coordinate-2$
$Inner-Radius$
$Inner-Radius$
$Start-Angle$
$Opening-Angle$
GML Arc-Band Template
7.4.2.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
8. Secondary Map Metadata
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
Thomson, et al. Expires August 30, 2010 [Page 18]
Internet-Draft Relative Location February 2010
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.
8.1. Map URL
In XML, the map is a