draft-ietf-geopriv-relative-location-00.txt   draft-ietf-geopriv-relative-location-01.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Andrew Corporation Internet-Draft Andrew Corporation
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: January 6, 2011 Neustar Expires: September 29, 2011 Neustar
D. Stanley D. Stanley
Aruba Networks Aruba Networks
G. Bajko G. Bajko
Nokia Nokia
A. Thomson A. Thomson
Cisco Systems, Inc. Cisco Systems, Inc.
July 5, 2010 March 28, 2011
Relative Location Representation Relative Location Representation
draft-ietf-geopriv-relative-location-00 draft-ietf-geopriv-relative-location-01
Abstract Abstract
This document defines an extension to PIDF-LO (RFC4119) for the This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a shapes. Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow coordinate system to the reference/offset coordinate system to allow
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7
5. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Relative Coordinate System . . . . . . . . . . . . . . . . 7
5.1. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7
5.2. Orientation of Relative Offset Coordinate Reference 4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8
System . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Distances and Angles . . . . . . . . . . . . . . . . . . . 8
6. Shape Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Units of Measure . . . . . . . . . . . . . . . . . . . . . 9 4.6. Relative Location Restrictions . . . . . . . . . . . . . . 9
6.2. Coordinates . . . . . . . . . . . . . . . . . . . . . . . 9 4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9
6.3. On Uncertainty and Encoding . . . . . . . . . . . . . . . 10 4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9
7. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 10 4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . . 11
7.1.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 10 4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . 12
7.2. Circle or Sphere Shape . . . . . . . . . . . . . . . . . . 11 4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . . 14
7.2.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 11 4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . . 17
7.2.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 12 4.10. Secondary Map Metadata . . . . . . . . . . . . . . . . . . 18
7.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . . . 12 4.10.1. Map URL . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 13 4.10.2. Map Coordinate Reference System . . . . . . . . . . . 19
7.3.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 14 4.10.3. Map Example . . . . . . . . . . . . . . . . . . . . . 21
7.4. Polygon or Prism Shape . . . . . . . . . . . . . . . . . . 14 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . 15 5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 22
7.4.2. TLV Encoding . . . . . . . . . . . . . . . . . . . . . 16 5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23
7.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25
7.5.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 18 6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25
7.5.2. TLV Encoding . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Secondary Map Metadata . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Map URL . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Relative Location Registry . . . . . . . . . . . . . . . . 28
8.2. Map Coordinate Reference System . . . . . . . . . . . . . 19 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 29
8.2.1. Map Reference Point Offset . . . . . . . . . . . . . . 19 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30
8.2.2. Map Orientation . . . . . . . . . . . . . . . . . . . 20 8.4. CRS public identifier registration . . . . . . . . . . . . 30
8.2.3. Map Scale . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8.3. Map Example . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
9.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23
9.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25
10. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. Relative Location Registry . . . . . . . . . . . . . . . . 28
12.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 29
12.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30
12.4. CRS public identifier registration . . . . . . . . . . . . 30
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document describes a format for the expression of relative This document describes a format for the expression of relative
location information. location information.
The location is given relative to a reference, which is expressed A relative location is formed of a reference location, plus a
with a civic or geodetic representation, with the relative offset as relative offset from that reference location. The reference location
described in this document. The offset is expressed in meters, and a can be represented in either civic or geodetic form. The reference
directional vector is either implied to be earth North/East or location can also have dynamic components such as velocity. The
supplied explicitly. Also defined is an optional URI to a document relative offset is specified in meters using a Cartesian coordinate
that can contain a map/floorplan/illustration ('map') upon which the system.
relative location can be plotted as well as an optional angle, offset
and scale defining the Coordinate Reference System (CRS) of the map. 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 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 PIDF-LO [RFC4119] and a TLV format for use in other protocols such as
those that already convey binary representation of location those that already convey binary representation of location
information defined in [RFC4776]. information defined in [RFC4776].
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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 3. Overview
This document describes an update to PIDF-LO [RFC4119] as updated by This document describes an extension to PIDF-LO [RFC4119] as updated
[RFC5139] and [RFC5491], to allow the expression of a location as an by [RFC5139] and [RFC5491], to allow the expression of a location as
offset relative to a reference. an offset relative to a reference.
This extension effectively allows the creator of a location object to This extension effectively allows the creator of a location object to
include two location values plus an offset. The "baseline" location include two location values plus an offset. The "baseline" location
that is given outside of the <relative-location> element is what will 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., be visible to a client that does not understand that extension (i.e.,
one that ignores the <relative-location> element). A client that one that ignores the <relative-location> element). A client that
does understand this extension will interpret the location within the does understand this extension will interpret the location within the
relative element as a refinement of the baseline location, which relative element as a refinement of the baseline location, which
gives the reference location for the relative offset. gives the reference location for the relative offset.
skipping to change at page 5, line 13 skipping to change at page 5, line 11
choice of how much information to put into the "baseline" location choice of how much information to put into the "baseline" location
and how much to put into the "reference" location. For example, all and how much to put into the "reference" location. For example, all
location information could be put inside the <relative-location> location information could be put inside the <relative-location>
element, so that clients that do not understand relative location element, so that clients that do not understand relative location
would receive no location information at all. Alternatively, the would receive no location information at all. Alternatively, the
baseline location value could be precise enough to specify a building baseline location value could be precise enough to specify a building
that contains the relative location, and the reference location could that contains the relative location, and the reference location could
specify a point within the building from which the offset is specify a point within the building from which the offset is
measured. measured.
In any case, it is RECOMMENDED that the baseline location be general The baseline location SHOULD be general enough to describe both the
enough to describe both the reference location and the relative reference location and the relative location (reference plus offset).
location (reference plus offset). In particular, while it is In particular, while it is possible to put all location information
possible to put all location information into the "reference" into the "reference" location (leaving an universally broad
location (leaving an universally broad "baseline"), location objects "baseline"), location objects SHOULD NOT have all location
SHOULD NOT have all location information in the baseline location. information in the baseline location. Doing this would cause clients
Doing this would cause clients that do not understand relative that do not understand relative location to incorrectly interpret the
location to incorrectly interpret the baseline location (i.e., the baseline location (i.e., the reference point) as the actual, precise
reference point) as the actual, precise location of the client. location of the client.
Both the baseline and the reference location are defined either as a Both the baseline and the reference location are defined either as a
geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If
the baseline location was expressed as a geodetic location, the the baseline location was expressed as a geodetic location, the
reference MUST be geodetic. If the baseline location was expressed reference MUST be geodetic. If the baseline location was expressed
as a civic address, the reference MUST be a civic. 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 The relative location can be expressed using a point (2- or
3-dimensional), or a shape that includes uncertainty: circle, sphere, 3-dimensional), or a shape that includes uncertainty: circle, sphere,
ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of
these shapes can be found in [RFC5491]. these shapes can be found in [RFC5491].
Optionally, a reference to a 'map' document can be provided. The Optionally, a reference to a 'map' document can be provided. The
reference is a URI. The document could be an image or dataset that 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 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 URI points to is described as a MIME media type. Metadata in the
relative location can include the location of the reference point in relative location can include the location of the reference point in
skipping to change at page 7, line 5 skipping to change at page 7, line 5
<rel:offset>20. 120.</rel:offset> <rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation> <rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale> <rel:scale>20. -20.</rel:scale>
</rel:map> </rel:map>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
4. Binary Format 4. Relative Location
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 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 Relative location is a shape (point, circle, ellipse...). The shape
is defined with a CRS that has a datum defined as the reference 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), (which appears as a civic address or geodetic location in the tuple),
and the shape coordinates as meter offsets North/East of the datum and the shape coordinates as meter offsets North/East of the datum
measured in meters (with an optional Z offset relative to datum measured in meters (with an optional Z offset relative to datum
altitude). An optional angle allows the reference CRS be to rotated altitude). An optional angle allows the reference CRS be to rotated
with respect to North. with respect to North.
The CRS for 2-D is denoted with an SRSname of 4.1. Relative Coordinate System
urn:ietf:params:geopriv:relative:2d, while the 3-D CRS is
urn:ietf:params:geopriv:relative:3d. A 2D offset MUST NOT be used The relative coordinate reference system uses a coordinate system
with a 3D reference, and a 3D offset MUST NOT be used with a 2D with two or three axes.
reference
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.
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- The baseline of the reference location is represented as <location-
info> like a normal PIDF-LO. Relative location adds a new <relative- info> like a normal PIDF-LO. Relative location adds a new <relative-
location> element to <location-info> Within <relative-location> location> element to <location-info> Within <relative-location>
<reference> and <offset> elements are described. Within <offset> are <reference> and <offset> elements are described. Within <offset> are
shape elements described below. shape elements described below.
The individual elements of the relative location have unique TLV 4.3. Binary Format
assignments. A relative location encoded in TLV would have the
baseline location reference TLDs followed by an outer reference TLD
which contains within it the reference refinement TLVs. The
reference TLD is 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. Reference TLV 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.
When a reference is encoded in TLV, the refinement of the baseline A type-length-value encoding is used.
location is represented in a reference TLV, inside of which are civic
CAtype TLVs (if the baseline was a civic) or geo TLVs (if the
baseline was a geo).
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
| 111 | Length | Reference TLVs | | Type |Length| Value ...
+------+------+------+------+------+------+
| X | N | Value label ...
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
Reference TLV Figure 1: TLV-tuple format
5.2. Orientation of Relative Offset Coordinate Reference System 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 relative location element may contain an optional angle relative The Length field (N) is defined as an unsigned integer that is one
to North that defines the CRS of the offset. The offset CRS scale is byte in length. This field can encode values from 0 to 255. The
always meters, and the datum is the reference. The angle is encoded length field describes the number of bytes in the Value. Length does
as a single precision floating point degrees, with 0.0 representing not count the bytes used for the Type or Length.
North. In xml, the angle is contained in an <ro-angle> element,
example <ro-angle>50.0</ro-angle>. In TLV encoding:
+------+------+------+------+------+------+------+ The Value field is defined separately for each type.
| 112 | Length | Angle |
+------+------+------+------+------+------+------+
Relative Offset Orientation TLV
6. Shape Encoding Each element of the relative location has a unique TLV assignment. A
relative location encoded in TLV would have the baseline location
TLVs, a reference location TLV which contains within it the reference
refinement TLVs. The reference TLVs are followed by the relative
offset, and optional map TLDs described in this document.
Shape data is used to represent regions of uncertainty in the 4.4. Distances and Angles
relative CRS.
The description of each shape type includes a description of how that All distance measures used in shapes are expressed in meters.
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 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).
All distance measures used in shapes are expressed in meters using 4.5. Value Encoding
single precision floating point values.
All orientation angles used in shapes are expressed in degrees using The binary form uses single-precision floating point values [IEEE754]
single precision floating point values. Orientation angles are to represent coordinates, distance and angle measures. Single
measured from WGS84 Northing to Easting with zero at Northing. precision values are 32-bit values with a sign bit, 8 exponent bits
Orientation angles in the relative coordinate system start from the and 23 fractional bits.
second coordinate axis (y or Northing) and increase toward the first
axis (x or Easting).
6.2. Coordinates 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].
Coordinates are a sequence of numeric values. These are encoded as a 4.6. Relative Location Restrictions
sequence of double precision floating point numbers.
Coordinates are represented using a single precision floating point More than one relative shape MUST NOT be included in either a PIDF-LO
value as described in IEEE 754 [IEEE.754]. or TLV encoding of location for a given reference point.
Every CRS MUST define how many values are present in each set of Any error in the reference point transfers to the location described
coordinates, the axes that each value applies to, the order of axes, by the relative location. Any errors arising from an implementation
and the units that are used for each axis. not supporting or understanding elements of the reference point
directly increases the error (or uncertainty) in the resulting
location.
For the two-dimensional CRS, coordinates are made of two values. The 4.7. Baseline TLVs
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, Baseline TLVs are defined in [RFC3825].
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.
6.3. On Uncertainty and Encoding 4.8. Reference TLV
Binary-encoded coordinate values are considered to be a single value When a reference is encoded in binary form, the baseline and
without uncertainty. When encoding a value that cannot be exactly reference locations are combined in a reference TLV. This TLV
represented, the best approximation is chosen according to contains civic address TLVs (if the baseline was a civic) or geo TLVs
[Clinger1990]. (if the baseline was a geo).
7. Shapes +------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
Reference TLV
If this TLV contains the reference location, then we need to
explicitly say that the shape TLVs in here use WGS84; and when the
shapes are outside of this, they use the relative:2d or relative:3d
forms.
TBD - Need TLVs for dynamic objects (orientation - multiple angles,
speed - single scalar, heading - multiple angles)
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 [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 target="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 types for 2d and
3d shapes.
Nine shape type codes are defined. Nine shape type codes are defined.
7.1. Point 4.9.1. Point
A point "shape" describes a single point with unknown uncertainty. A point "shape" describes a single point with unknown uncertainty.
It consists of a single set of coordinates. It consists of a single set of coordinates.
In a two-dimensional CRS, the coordinate includes two values; in a In a two-dimensional CRS, the coordinate includes two values; in a
three-dimensional CRS, the coordinate includes three values. three-dimensional CRS, the coordinate includes three values.
7.1.1. XML encoding 4.9.1.1. XML encoding
A point is represented in GML using the following template: A point is represented in GML using the following template:
<gml:Point xmlns:gml="http://www.opengis.net/gml" <gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$"> srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point> </gml:Point>
GML Point Template GML Point Template
Where "$CRS-URN$" is replaced by a Where "$CRS-URN$" is replaced by a
urn:ietf:params:geopriv:relative:2d or urn:ietf:params:geopriv:relative:2d or
urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted
if the CRS is two-dimensional. if the CRS is two-dimensional.
7.1.2. TLV encoding 4.9.1.2. TLV encoding
The point shape is introduced by a TLV of 113 for a 2D point and 114 The point shape is introduced by a TLV of 113 for a 2D point and 114
for a 3D point. for a 3D point.
+------+-------------+ +------+------+
| 113/4| Length | | 113/4|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
Point Encoding Point Encoding
7.2. Circle or Sphere Shape 4.9.2. Circle or Sphere Shape
A circle or sphere describes a single point with a single uncertainty A circle or sphere describes a single point with a single uncertainty
value in meters. value in meters.
In a two-dimensional CRS, the coordinate includes two values and the In a two-dimensional CRS, the coordinate includes two values and the
resulting shape forms a circle. In a three-dimensional CRS, the resulting shape forms a circle. In a three-dimensional CRS, the
coordinate includes three values and the resulting shape forms a coordinate includes three values and the resulting shape forms a
sphere. The uncertainty radius is specified as a single precision sphere.
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 4.9.2.1. XML encoding
A circle is represented in and converted from GML using the following A circle is represented in and converted from GML using the following
template: template:
<gs:Circle xmlns:gml="http://www.opengis.net/gml" <gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$ $Radius$
skipping to change at page 12, line 5 skipping to change at page 12, line 19
xmlns:gml="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d"> srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$ $Radius$
</gs:radius> </gs:radius>
</gs:Sphere> </gs:Sphere>
GML Sphere Template GML Sphere Template
7.2.2. TLV encoding 4.9.2.2. TLV encoding
A circular shape is introduced by a type code of 115. A spherical A circular shape is introduced by a type code of 115. A spherical
shape is introduced by a type code of 116. shape is introduced by a type code of 116.
+------+-------------+ +------+------+
| 115/6| Length | | 115/6|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
| Radius | | Radius |
+------+------+------+------+ +------+------+------+------+
Circle or Sphere Encoding Circle or Sphere Encoding
7.3. Ellipse or Ellipsoid Shape 4.9.3. Ellipse or Ellipsoid Shape
A ellipse or ellipsoid describes a point with an elliptical or A ellipse or ellipsoid describes a point with an elliptical or
ellipsoidal uncertainty region. ellipsoidal uncertainty region.
In a two-dimensional CRS, the coordinate includes two values, plus a In a two-dimensional CRS, the coordinate includes two values, plus a
semi-major axis, a semi-minor axis, a semi-major axis orientation semi-major axis, a semi-minor axis, a semi-major axis orientation
(clockwise from North). In a three-dimensional CRS, the coordinate (clockwise from North). In a three-dimensional CRS, the coordinate
includes three values and in addition to the two-dimensional values, includes three values and in addition to the two-dimensional values,
an altitude uncertainty (semi-vertical) is added. an altitude uncertainty (semi-vertical) is added.
Distance and angular measures are defined in meters and degrees 4.9.3.1. XML encoding
respectively. Both are encoded as single precision floating point
values.
7.3.1. XML encoding
An ellipse is represented in and converted from GML using the An ellipse is represented in and converted from GML using the
following template: following template:
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml" <gs:Ellipse xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$ $Semi-Major$
skipping to change at page 14, line 5 skipping to change at page 14, line 5
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$ $Semi-Vertical$
</gs:verticalAxis> </gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$ $Orientation$
</gs:orientation> </gs:orientation>
</gs:Ellipsoid> </gs:Ellipsoid>
GML Ellipsoid Template GML Ellipsoid Template
7.3.2. TLV encoding 4.9.3.2. TLV encoding
An ellipse is introduced by a type code of 117 and an ellipsoid is An ellipse is introduced by a type code of 117 and an ellipsoid is
introduced by a type code of 118. introduced by a type code of 118.
+------+-------------+ +------+------+
| 117/8| Length | | 117/8|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis | | Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis | | Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
Ellipse or Ellipsoid Encoding Ellipse or Ellipsoid Encoding
7.4. Polygon or Prism Shape 4.9.4. Polygon or Prism Shape
A polygon or prism include a number of points that describe the outer A polygon or prism include a number of points that describe the outer
boundary of an uncertainty region. A prism also includes an altitude boundary of an uncertainty region. A prism also includes an altitude
and prism height. for each point and prism height.
At least 3 points MUST be included in a polygon. In order to At least 3 points MUST be included in a polygon. In order to
interoperate with existing systems, an encoding SHOULD include 15 or interoperate with existing systems, an encoding SHOULD include 15 or
fewer points, unless the recipient is known to support larger fewer points, unless the recipient is known to support larger
numbers. numbers.
The height of the prism is encoded as a single precision floating 4.9.4.1. XML Encoding
point value.
7.4.1. XML Encoding
A polygon is represented in and converted from GML using the A polygon is represented in and converted from GML using the
following template: following template:
<gml:Polygon xmlns:gml="http://www.opengis.net/gml" <gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-1$ $Coordinate1-2$
skipping to change at page 15, line 29 skipping to change at page 15, line 29
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-1$ $Coordinate1-2$
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
GML Polygon Template GML Polygon Template
Alternatively, a series of "pos" elements can be used in place of the Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains two coordinate values. 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 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 coordinates and no explicit count of the number of points is
provided. provided.
A GML polygon that includes altitude cannot be represented completely A GML polygon that includes altitude cannot be represented completely
in binary. When converting to the binary representation, a two in binary. When converting to the binary representation, a two
dimensional CRS is used and altitude is removed from each coordinate. dimensional CRS is used and altitude is removed from each coordinate.
A prism is represented in and converted from GML using the following A prism is represented in and converted from GML using the following
skipping to change at page 16, line 38 skipping to change at page 16, line 38
$Height$ $Height$
</gs:height> </gs:height>
</gs:Prism> </gs:Prism>
GML Prism Template GML Prism Template
Alternatively, a series of "pos" elements can be used in place of the Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains three coordinate single "posList". Each "pos" element contains three coordinate
values. values.
7.4.2. TLV Encoding 4.9.4.2. TLV Encoding
A polygon is introduced with a type code of 119. A prism is A polygon containing 2D points is uses a type code of 119. A polygon
introduced with a type code of 120. with 3D points uses a type code of 120. A prism uses a type code of
121.
+------+-------------+ +------+------+
|119/20| Length | |119-21|Length|
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| Count | (3D-only) Height | | Count | (3D-only) Height |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| Coordinate1-1 | | Coordinate1-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate1-2 | | Coordinate1-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate1-3 | | (3D-only) Coordinate1-3 |
+------+------+------+------+ +------+------+------+------+
| Coordinate2-1 | | Coordinate2-1 |
skipping to change at page 17, line 30 skipping to change at page 17, line 30
| CoordinateN-1 | | CoordinateN-1 |
+------+------+------+------+ +------+------+------+------+
| CoordinateN-2 | | CoordinateN-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) CoordinateN-3 | | (3D-only) CoordinateN-3 |
+------+------+------+------+ +------+------+------+------+
Polygon or Prism Encoding Polygon or Prism Encoding
Note that unlike the polygon representation in GML, the first and Note that unlike the polygon representation in GML, the first and
last points are not required to be the same in the TLV last points are not the same point to be the same in the TLV
representation. an explicit count of the number of points is provided representation. The duplicated point is removed from the binary
in 'Count'. form.
7.5. Arc-Band Shape 4.9.5. Arc-Band Shape
A arc-band describes a region constrained by a range of angles and A arc-band describes a region constrained by a range of angles and
distances from a predetermined point. This shape can only be distances from a predetermined point. This shape can only be
provided for a two-dimensional CRS. provided for a two-dimensional CRS.
Distance and angular measures are defined in meters and degrees Distance and angular measures are defined in meters and degrees
respectively. Both are encoded as single precision floating point respectively. Both are encoded as single precision floating point
values. values.
7.5.1. XML encoding 4.9.5.1. XML encoding
An arc-band is represented in and converted from GML using the An arc-band is represented in and converted from GML using the
following template: following template:
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml" <gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$ $Inner-Radius$
skipping to change at page 18, line 30 skipping to change at page 18, line 30
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$ $Start-Angle$
</gs:startAngle> </gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$ $Opening-Angle$
</gs:openingAngle> </gs:openingAngle>
</gs:Ellipsoid> </gs:Ellipsoid>
GML Arc-Band Template GML Arc-Band Template
7.5.2. TLV Encoding 4.9.5.2. TLV Encoding
An arc-band is introduced by a type code of 122. An arc-band is introduced by a type code of 122.
+------+-------------+ +------+------+
| 121 | Length | | 122 |Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate | | Coordinate |
+------+------+------+------+ +------+------+------+------+
| Coordinate | | Coordinate |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius | | Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle | | Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
Arc-Band Encoding Arc-Band Encoding
8. Secondary Map Metadata 4.10. Secondary Map Metadata
The optional "map" URL can be used to provide a user of relative The optional "map" URL can be used to provide a user of relative
location with a visual reference for the location information. This location with a visual reference for the location information. This
document does not describe how the recipient uses the map nor how it 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 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 images, vector files, 2-D or 3-D geospatial databases, or any other
form of representation understood by both the sender and recipient. form of representation understood by both the sender and recipient.
8.1. Map URL 4.10.1. Map URL
In XML, the map is a <map> element defined within <relative-location> 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. 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 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 the PIDF-LO is able to ensure that authorized recipients of this data
are able to use other URI schemes. A "map-type" attribute MUST be 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 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 are specified as mime media types as recorded in the IANA Media Types
registry. For example <map map-type="image/png">https:// registry. For example <map type="image/png">https://www.example.com/
www.example.com/floorplans/123South/floor-2</map>. In binary, the floorplans/123South/floor-2</map>. In binary, the map type is a
maptype is a separate TLV from the map URL: separate TLV from the map URL:
+------+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 122 | Length | maptype ... | 123 |Length| Map Media Type ...
+------+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 123 | Length | Map Image URL ... | 124 |Length| Map Image URL ...
+------+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
Map URL TLVs Map URL TLVs
8.2. Map Coordinate Reference System 4.10.2. Map Coordinate Reference System
The CRS used by the map depends on the type of map. For example, a 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 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 complete CRS description in it. For some kinds of maps, typically
described as images, the CRS used within the map must define the described as images, the CRS used within the map must define the
following: following:
o The CRS origin o The CRS origin
o The CRS axes used and their orientation o The CRS axes used and their orientation
o The unit of measure used o The unit of measure used
This document provides elements that allow for a mapping between the This document provides elements that allow for a mapping between the
local coordinate reference system used for the relative location and local coordinate reference system used for the relative location and
the coordinate reference system used for the map where they are not the coordinate reference system used for the map where they are not
the same. the same.
8.2.1. Map Reference Point Offset 4.10.2.1. Map Reference Point Offset
This optional element identifies the coordinates of the reference This optional element identifies the coordinates of the reference
point as it appears in the map. This value is measured in a map-type point as it appears in the map. This value is measured in a map-type
dependent manner, using the coordinate system of the map. dependent manner, using the coordinate system of the map.
For image maps, coordinates start from the upper left corner and For image maps, coordinates start from the upper left corner and
coordinates are first counted by column with positive values to the coordinates are first counted by column with positive values to the
right; then rows are counted with positive values toward the bottom right; then rows are counted with positive values toward the bottom
of the image. For such an image, the first item is columns, the 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 second rows and any third value applies to any third dimension used
in the image coordinate space. in the image coordinate space.
The <map-offset> element contains 2 (or 3) coordinates similar to a The <offset> element contains 2 (or 3) coordinates similar to a GML
GML "pos", For example: "pos", For example:
<map-offset> 2670.0 1124.0 1022.0</map-offset> <offset> 2670.0 1124.0 1022.0</offset>
Map Reference Point Example XML Map Reference Point Example XML
+------+-------------+ +------+------+
| 124 | Length | | 125 |Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
Map Reference Point Coordinates TLV Map Reference Point Coordinates TLV
The encoding for coordinates is described in Section 6.2.
If omitted, a value containing all zeros is assumed. If the If omitted, a value containing all zeros is assumed. If the
coordinates provided contain fewer values than are needed, the first coordinates provided contain fewer values than are needed, the first
value from the set is applied in place of any missing values. value from the set is applied in place of any missing values.
8.2.2. Map Orientation 4.10.2.2. Map Orientation
The map orientation includes the orientation of the map direction The map orientation includes the orientation of the map direction in
('UP') in relation to the Earth. Map orientation is expressed relation to the Earth. Map orientation is expressed relative to the
relative to the orientation of the relative coordinate system. This orientation of the relative coordinate system. This means that map
means that map orientation with respect to WGS84 North is the sum of orientation with respect to WGS84 North is the sum of th orientation
the two orientation fields. Both values default to zero if no value field, plus any orientation included in a dynamic portion of the
is specified. reference location. Both values default to zero if no value is
specified.
This type uses a single precision floating point value of degrees This type uses a single precision floating point value of degrees
relative to North. relative to North.
In XML, the <orientation> element contains a single floating point In XML, the <orientation> element contains a single floating point
value, example <orientation>67.00</orientation>. In TLV form: value, example <orientation>67.00</orientation>. In TLV form:
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 125 | Length | Angle | | 126 |Length| Angle |
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+
Map Orientation TLV Map Orientation TLV
8.2.3. Map Scale 4.10.2.3. Map Scale
The optional map scale describes the relationship between the units The optional map scale describes the relationship between the units
of measure used in the map, relative to the meters unit used in the of measure used in the map, relative to the meters unit used in the
relative coordinate system. relative coordinate system.
This type uses a sequence of IEEE 754 [IEEE.754] single precision This type uses a sequence of IEEE 754 [IEEE.754] single precision
floating point values to represent scale as a sequence of numeric floating point values to represent scale as a sequence of numeric
values. The units of these values is map-type dependent, and could values. The units of these values is dependent on the type of map,
for example be pixels per meter in image map-types. and could for example be pixels per meter for an image.
A scaling factor is provided for each axis in the coordinate system. A scaling factor is provided for each axis in the coordinate system.
For a two-dimensional coordinate system, two values are included to For a two-dimensional coordinate system, two values are included to
allow for different scaling along the x and y axes independently. allow for different scaling along the x and y axes independently.
For a three-dimensional coordinate system, three values are specified For a three-dimensional coordinate system, three values are specified
for the x, y and z axes. for the x, y and z axes.
Alternatively, a single scaling value MAY be used to apply the same Alternatively, a single scaling value MAY be used to apply the same
scaling factor to all coordinate components. scaling factor to all coordinate components.
Images that use a rows/columns coordinate system often use a left- Images that use a rows/columns coordinate system often use a left-
handed coordinate system. A negative value for the y/rows-axis handed coordinate system. A negative value for the y/rows-axis
scaling value can be used to account for any change in direction scaling value can be used to account for any change in direction
between the y-axis used in the relative coordinate system and the between the y-axis used in the relative coordinate system and the
rows axis of the image coordinate system. rows axis of the image coordinate system.
In XML, the <scale> element may contain the single scale value, or 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 may contain 2 (or 3) values similar to a GML "pos" with separate
scale values. In TLV form: scale values. In TLV form:
+------+------+------+------+------+------+ +------+------+------+------+------+
| 126 | Length | Scales ... | 127 |Length| Scales ...
+------+------+------+------+------+------+ +------+------+------+------+------+
Map Scale TLV Map Scale TLV
8.3. Map Example 4.10.3. Map Example
An example of expressing a map is: An example of expressing a map is:
<rel:map> <rel:map>
<rel:url type="image/jpeg"> <rel:url type="image/jpeg">
http://example.com/map.jpg http://example.com/map.jpg
</rel:url> </rel:url>
<rel:offset>200 210</rel:offset> <rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation> <rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale> <rel:scale>2.90 -2.90</rel:scale>
</rel:map> </rel:map>
Map Example Map Example
9. Examples 5. Examples
9.1. Civic PIDF with Polygon Offset 5.1. Civic PIDF with Polygon Offset
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com"> entity="pres:ness@example.com">
<dm:device id="nesspc-1"> <dm:device id="nesspc-1">
skipping to change at page 23, line 30 skipping to change at page 23, line 26
</rel:relative-location> </rel:relative-location>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>GPS</gp:method> <gp:method>GPS</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
9.2. Geo PIDF with Circle Offset 5.2. Geo PIDF with Circle Offset
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:point2d@example.com"> entity="pres:point2d@example.com">
<dm:device id="point2d"> <dm:device id="point2d">
<gp:geopriv> <gp:geopriv>
skipping to change at page 25, line 5 skipping to change at page 25, line 5
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
9.3. Civic TLV with Point Offset 5.3. Civic TLV with Point Offset
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
| Type | Value | | Type | Value |
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
| 0 | en | | 0 | en |
| | | | | |
| 1 | IL | | 1 | IL |
| | | | | |
| 3 | Chicago | | 3 | Chicago |
| | | | | |
skipping to change at page 25, line 34 skipping to change at page 25, line 34
| 40 | BBuilding|A | | 40 | BBuilding|A |
| | | | | |
| 40 | AFloor|6th | | 40 | AFloor|6th |
| | | | | |
| 40 | BSuite|213 | | 40 | BSuite|213 |
| | | | | |
| 40 | ADoor|Front | | 40 | ADoor|Front |
| | | | | |
| 115 | 100 70 | | 115 | 100 70 |
| | | | | |
| 122 | image/png | | 123 | image/png |
| | | | | |
| 123 | http://maps.example.com/3400Wacker/A6 | | 124 | http://maps.example.com/3400Wacker/A6 |
| | | | | |
| 124 | 0.0 4120.0 | | 125 | 0.0 4120.0 |
| | | | | |
| 125 | 113.0 | | 126 | 113.0 |
| | | | | |
| 126 | 10.6 | | 127 | 10.6 |
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
10. Schema Definition 6. Schema Definition
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 28, line 12 skipping to change at page 28, line 12
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="doubleList"> <xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/> <xs:list itemType="xs:double"/>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
xml schema relative-location xml schema relative-location
11. Security Considerations 7. Security Considerations
This document describes a data format. To a large extent, security This document describes a data format. To a large extent, security
properties of this depend on how this data is used. properties of this depend on how this data is used.
Privacy for location data is typically important. Adding relative Privacy for location data is typically important. Adding relative
location may increase the precision of the location, but does not location may increase the precision of the location, but does not
otherwise alter its privacy considerations, which are discussed in otherwise alter its privacy considerations, which are discussed in
[RFC4119] [RFC4119]
[[Not that interesting, but it could be relevant ?]] The fractional [[Not that interesting, but it could be relevant ?]] The fractional
bits in IEEE 754 [IEEE.754] floating point values can be used as a 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 covert channel. For values of either zero or infinity, non-zero
fraction bits could be used to convey information. If the presence fraction bits could be used to convey information. If the presence
of covert channels is not desired then the fractional bits MUST be 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 set to zero. There is no need to represent NaN (not a number) in
this encoding. this encoding.
12. IANA Considerations 8. IANA Considerations
12.1. Relative Location Registry 8.1. Relative Location Registry
This document creates a new registry called 'RLtypes'. As defined in This document creates a new registry called 'Relative Location
[RFC5226], this registry operates under "IETF Consensus" rules. Parameters'. As defined in [RFC5226], this registry operates under
"IETF Consensus" rules.
The content of this registry includes: The content of this registry includes:
RLtype: Numeric identifier, assigned by IANA. Relative Location Code: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the Brief description: Short description identifying the meaning of the
element. element.
Reference to published specification: A stable reference to an RFC Reference to published specification: A stable reference to an RFC
which describes the value in sufficient detail so that which describes the value in sufficient detail so that
interoperability between independent implementations is possible. interoperability between independent implementations is possible.
IANA is requested to not permit values to be assigned into this IANA is requested to not permit values to be assigned into this
registry which conflict with values assigned in the CAtypes registry registry which conflict with values assigned in the CAtypes registry
skipping to change at page 29, line 17 skipping to change at page 29, line 18
The values defined are: The values defined are:
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| RLtype | description | Reference | | RLtype | description | Reference |
+--------+-------+--------------------------------+-----------+ +--------+-------+--------------------------------+-----------+
| 111 | relative location reference | this RFC | | 111 | relative location reference | this RFC |
| 112 | relative location angle | this RFC | | 112 | relative location angle | this RFC |
| 113 | relative location shape 2D point | this RFC | | 113 | relative location shape 2D point | this RFC |
| 114 | relative location shape 3D point | this RFC | | 114 | relative location shape 3D point | this RFC |
| 115 | relative location shape circlular | this RFC | | 115 | relative location shape circular | this RFC |
| 116 | relative location shape spherical | this RFC | | 116 | relative location shape spherical | this RFC |
| 117 | relative location shape elliptical | this RFC | | 117 | relative location shape elliptical | this RFC |
| 118 | relative location shape ellipsoid | this RFC | | 118 | relative location shape ellipsoid | this RFC |
| 119 | relative location shape arc-band | this RFC | | 119 | relative location shape arc-band | this RFC |
| 120 | relative location shape polygon | this RFC | | 120 | relative location shape 2D polygon | this RFC |
| 121 | relative location shape 3D polygon | this RFC |
| 121 | relative location shape prism | this RFC | | 121 | relative location shape prism | this RFC |
| 122 | relative location map type | this RFC | | 122 | relative location map type | this RFC |
| 123 | relative location map URI | this RFC | | 123 | relative location map URI | this RFC |
| 124 | relative location map coordinates | this RFC | | 124 | relative location map coordinates | this RFC |
| 125 | relative location map angle | this RFC | | 125 | relative location map angle | this RFC |
| 126 | relative location map scale | this RFC | | 126 | relative location map scale | this RFC |
+--------+-------+--------------------------------+-----------+ +--------+-------+--------------------------------+-----------+
12.2. URN Sub-Namespace Registration 8.2. URN Sub-Namespace Registration
This document registers a new XML namespace, as per the guidelines in This document registers a new XML namespace, as per the guidelines in
[RFC3688]) that has been registered with IANA. [RFC3688]) that has been registered with IANA.
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
XML: XML:
skipping to change at page 30, line 32 skipping to change at page 30, line 32
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p> RFCXXXX</a>.</p>
</body> </body>
</html> </html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published with the number of the published
document and remove this note.]] --> document and remove this note.]] -->
END END
12.3. XML Schema Registration 8.3. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
The XML for this schema can be found as the entirety of Section 7 The XML for this schema can be found as the entirety of Section 7
of this document. of this document.
12.4. CRS public identifier registration 8.4. CRS public identifier registration
This section registers two public identifiers as per the procedures This section registers two public identifiers as per the procedures
in [RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
XML: XML:
skipping to change at page 32, line 8 skipping to change at page 32, line 8
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p> RFCXXXX</a>.</p>
</body> </body>
</html> </html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published with the number of the published
document and remove this note.]] --> document and remove this note.]] -->
END END
13. Acknowledgements 9. Acknowledgements
This is the product of a design team on relative location. Besides This is the product of a design team on relative location. Besides
the authors, this team included: Marc Linsner, James Polk, and James the authors, this team included: Marc Linsner, James Polk, and James
Winterbottom. Winterbottom.
14. References 10. References
14.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic
Host Configuration Protocol Option for Coordinate-
based Location Configuration Information", RFC 3825,
July 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location
Object Format", RFC 4119, December 2005. Object Format", RFC 4119, December 2005.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration [RFC4776] Schulzrinne, H., "Dynamic Host Configuration
Protocol (DHCPv4 and DHCPv6) Option for Civic Protocol (DHCPv4 and DHCPv6) Option for Civic
Addresses Configuration Information", RFC 4776, Addresses Configuration Information", RFC 4776,
November 2006. November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic
Location Format for Presence Information Data Format Location Format for Presence Information Data Format
skipping to change at page 32, line 43 skipping to change at page 32, line 48
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008. BCP 26, RFC 5226, May 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig,
"GEOPRIV Presence Information Data Format Location "GEOPRIV Presence Information Data Format Location
Object (PIDF-LO) Usage Clarification, Object (PIDF-LO) Usage Clarification,
Considerations, and Recommendations", RFC 5491, Considerations, and Recommendations", RFC 5491,
March 2009. 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.
[OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A.
Whiteside, "Geographic information - Geography Whiteside, "Geographic information - Geography
Markup Language (GML)", OpenGIS 03-105r1, Markup Language (GML)", OpenGIS 03-105r1,
April 2004, <http://portal.opengeospatial.org/files/ April 2004, <http://portal.opengeospatial.org/files/
?artifact_id=4700>. ?artifact_id=4700>.
[OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape [OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Application Schema for use by the Internet
Engineering Task Force (IETF)", OGC Best Engineering Task Force (IETF)", OGC Best
Practice 06-142r1, Version: 1.0, April 2007. Practice 06-142r1, Version: 1.0, April 2007.
skipping to change at page 33, line 17 skipping to change at page 33, line 27
[IEEE.754] IEEE, "IEEE Standard for Binary Floating-Point [IEEE.754] IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", IEEE Standard 754-1985, January 2003. Arithmetic", IEEE Standard 754-1985, January 2003.
[Clinger1990] Clinger, W., "How to Read Floating Point Numbers [Clinger1990] Clinger, W., "How to Read Floating Point Numbers
Accurately", Proceedings of Conference on Accurately", Proceedings of Conference on
Programming Language Design and Implementation pp. Programming Language Design and Implementation pp.
92-101, 1990, 92-101, 1990,
<ftp://ftp.ccs.neu.edu/pub/people/will/ <ftp://ftp.ccs.neu.edu/pub/people/will/
howtoread.ps>. howtoread.ps>.
14.2. Informative References 10.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
RFC 3688, January 2004. RFC 3688, January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
Authors' Addresses Authors' Addresses
 End of changes. 105 change blocks. 
295 lines changed or deleted 291 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/