One document matched: draft-ietf-geopriv-relative-location-06.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1014 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1014.xml">
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3553 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3863 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3863.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC4479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml">
<!ENTITY RFC4776 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml">
<!ENTITY RFC5139 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5491 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml">
<!ENTITY RFC5962 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5962.xml">
<!ENTITY RFC6225 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6225.xml">
<!ENTITY RFC6848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6848.xml">
]>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-geopriv-relative-location-06">
<front>
<title abbrev="Relative Location">
Relative Location Representation
</title>
<author initials="M" surname="Thomson" fullname="Martin Thomson">
<organization>Microsoft</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>
<phone>+1 650-353-1925</phone>
<email>martin.thomson@skype.net</email>
</address>
</author>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>Neustar</organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<author initials="D." surname="Stanley" fullname="Dorothy Stanley">
<organization>Aruba Networks</organization>
<address>
<postal>
<street>1322 Crossman Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>dstanley@arubanetworks.com</email>
</address>
</author>
<author initials="G." surname="Bajko" fullname="Gabor Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street>323 Fairchild Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>gabor.bajko@nokia.com</email>
</address>
</author>
<author initials="A." surname="Thomson" fullname="Allan Thomson">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>althomso@cisco.com</email>
</address>
</author>
<date year="2013"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Relative</keyword>
<keyword>location</keyword>
<abstract>
<t>
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. An alternative binary representation is described.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document describes a format for the expression of relative location information.
</t>
<t>
A relative location is formed of a reference location, plus a relative offset from that
reference location. The reference location can be represented in either civic or geodetic
form. The reference location can also have dynamic components such as velocity. The
relative offset is specified in meters using a Cartesian coordinate system.
</t>
<t>
In addition to the relative location, an optional URI can be provided to a document that
contains a map, floorplan or other spatially oriented information. Applications could use
this information to display the relative location. Additional fields allow the map to be
oriented and scaled correctly.
</t>
<t>
Two formats are included: an XML form that is intended for use in PIDF-LO <xref
target="RFC4119"/> and a TLV format for use in other protocols such as those that already
convey binary representation of location information defined in <xref target="RFC4776"/>.
</t>
</section>
<section anchor="conventions" title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>.
</t>
</section>
<section title="Overview">
<t>
This document describes an extension to PIDF-LO <xref target="RFC4119"/> as updated by <xref
target="RFC5139"/> and <xref target="RFC5491"/>, to allow the expression of a location as an
offset relative to a reference.
</t>
<figure>
<artwork><![CDATA[
Reference
Location
o
\
\ Offset
\
_\|
x
Relative
Location
]]></artwork>
</figure>
<t>
This extension allows the creator of a location object to include two location values plus
an offset. The two location values, named "baseline" and "reference", combine to form the
origin of the offset. The final, relative location is described relative to this reference
point.
</t>
<figure>
<artwork><![CDATA[
..--"""--..
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'
]]></artwork>
</figure>
<t>
The "baseline" location is included outside of the <relative-location> element. The
baseline location is visible to a client that does not understand relative location (i.e.,
it ignores the <relative-location> element).
</t>
<t>
A client that does understand relative location will interpret the location within the
relative element as a refinement of the baseline location. This document defines both a
"reference" location, which serves as a refinement of the baseline location and the starting
point; and an offset, which describes the location of the Target based on this starting
point.
</t>
<t>
Creators of location objects with relative location thus have a choice of how much
information to put into the "baseline" location and how much to put into the "reference"
location. For example, the baseline location value could be precise enough to specify a
building that contains the relative location, and the reference location could specify a
point within the building from which the offset is measured.
</t>
<t>
Location objects SHOULD NOT have all location information in the baseline location. Doing
this would cause clients that do not understand relative location to incorrectly interpret
the baseline location (i.e., the reference point) as the actual, precise location of the
client. The baseline location is intended to carry a location that encompasses both the
reference location and the relative location (i.e., the reference location plus offset).
</t>
<t>
It is possible to provide a valid relative location with no information in the baseline.
However, this provides recipients who do not understand relative location with no
information. A baseline location SHOULD include sufficient information to encompass both
the reference and relative locations while providing a baseline that is as accurate as
possible.
</t>
<t>
Both the baseline and the reference location are defined either as a <xref
target="OGC.GeoShape">geodetic location</xref> or a <xref target="RFC4776">civic
address</xref>. If the baseline location was expressed as a geodetic location, the
reference MUST be geodetic. If the baseline location was expressed as a civic address, the
reference MUST be a civic.
</t>
<t>
Baseline and reference locations MAY also include dynamic location information <xref
target="RFC5962"/>.
</t>
<t>
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 <xref target="RFC5491"/>.
</t>
<t>
Optionally, a reference to a 'map' document can be provided. The reference is a URI. The
document could be an image or dataset that represents a map, floorplan or other form. The
type of document the URI points to is described as a MIME media type. Metadata in the
relative location can include the location of the reference point in the map as well as an
orientation (angle from North) and scale to align the document Co-ordinate Reference System
(CRS) with the WGS84 <xref target="WGS84"/> CRS. The document is assumed to be useable by
the application receiving the PIDF with the relative location to locate the reference point
in the map. This document does not describe any mechanisms for displaying or manipulating
the document other than providing the reference location, orientation and scale.
</t>
<figure>
<preamble>
As an example, consider a relative location expressed as a point, relative to a civic
location:
</preamble>
<artwork><![CDATA[
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:relative@example.com">
<dm:device id="relative1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos>
</gml:Point>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
<rel:map>
<rel:url type="image/png">
http://example.com/location/map.png
</rel:url>
<rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale>
</rel:map>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
]]></artwork>
</figure>
</section>
<section anchor="tlv-relative" title="Relative Location">
<t>
Relative location is a shape (e.g., point, circle, ellipse). The shape is defined with a CRS
that has a datum defined as the reference (which appears as a civic address or geodetic location
in the tuple), and the shape coordinates as meter offsets North/East of the datum measured in
meters (with an optional Z offset relative to datum altitude). An optional angle allows the
reference CRS be to rotated with respect to North.
</t>
<section title="Relative Coordinate System">
<t>
The relative coordinate reference system uses a coordinate system with two or three axes.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Any coordinates in the relative shapes use the described Cartesian coordinate system. In the
XML form, this uses a URN of <spanx style="verb">urn:ietf:params:geopriv:relative:2d</spanx>
for two-dimensional shapes and <spanx style="verb">urn:ietf:params:geopriv:relative:3d</spanx>
for three-dimensional shapes. The binary form uses different shape type identifiers for 2D
and 3D shapes.
</t>
<t>
Dynamic location information <xref target="RFC5962"/> in the baseline or reference location
alters relative coordinate system. The resulting Cartesian coordinate system axes are rotated
so that the <spanx style="verb">y</spanx> axis is oriented along the direction described by
the <orientation> element. The coordinate system also moves as described by the
<speed> and <heading> elements.
</t>
<t>
The single timestamp included in the tuple (or equivalent) element applies to all location
elements, including all three components of a relative location: baseline, reference and
relative. This is particularly important when there are dynamic components to these
items. A location generator is responsible for ensuring the consistency of these fields.
</t>
</section>
<section title="Placement of XML Elements">
<t>
The baseline of the reference location is represented as <location-info> like a normal
PIDF-LO. Relative location adds a new <relative-location> element to
<location-info>. Within <relative-location>, <reference> and <offset>
elements are described. Within <offset> are the shape elements described below. This
document extends PIDF-LO as described in <xref target="RFC6848"/>.
</t>
</section>
<section anchor="tlv-top" title="Binary Format">
<t>
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.
</t>
<t>
A type-length-value encoding is used.
</t>
<figure anchor="tlv-format" title="TLV-tuple format">
<artwork><![CDATA[
+------+------+------+------+------+------+------+
| Type |Length| Value ...
+------+------+------+------+------+------+------+
| T | N | Value ...
+------+------+------+------+------+------+------+
]]></artwork>
</figure>
<t>
Type field (T) is an 8-bit unsigned integer. The type codes used are registered an
IANA-managed "Relative Location Parameters" 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 within the same object without type collisions.
</t>
<t>
The Length field (N) is defined as an 8-bit unsigned integer. This field can encode values
from 0 to 255. The length field describes the number of bytes in the Value. Length does
not count the bytes used for the Type or Length.
</t>
<t>
The Value field is defined separately for each type.
</t>
<t>
Each element of the relative location has a unique TLV assignment. A relative location
encoded in TLV form includes both baseline and reference location TLVs and a reference
location TLVs. The reference TLVs are followed by the relative offset, and optional map
TLDs described in this document.
</t>
</section>
<section title="Distances and Angles">
<t>
All distance measures used in shapes are expressed in meters.
</t>
<t>
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).
</t>
</section>
<section title="Value Encoding">
<t>
The binary form uses single-precision floating point values <xref target="IEEE.754"> IEEE
754</xref> to represent coordinates, distance and angle measures. Single precision values
are 32-bit values with a sign bit, 8 exponent bits and 23 fractional bits. This uses the
interchange format defined in <xref target="IEEE.754"/> and Section 3.6 of <xref
target="RFC1014"/>, that is: sign, biased exponent and significand, with the most
significant bit first.
</t>
<t>
Binary-encoded coordinate values are considered to be a single value without uncertainty.
When encoding a value that cannot be exactly represented, the best approximation MUST be
selected according to <xref target="Clinger1990"/>.
</t>
</section>
<section title="Relative Location Restrictions">
<t>
More than one relative shape MUST NOT be included in either a PIDF-LO or TLV encoding of
location for a given reference point.
</t>
<t>
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.
</t>
</section>
<section title="Baseline TLVs">
<t>
Baseline locations are described using the formats defined in <xref target="RFC4776"/>
or <xref target="RFC6225"/>.
</t>
</section>
<section anchor="reference" title="Reference TLV">
<t>
When a reference is encoded in binary form, the baseline and reference locations are
combined in a reference TLV. This TLV is identified with the code 111 and contains civic
address TLVs (if the baseline was a civic) or geo TLVs (if the baseline was a geo).
</t>
<figure title="Reference TLV">
<artwork><![CDATA[
+------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
]]></artwork>
</figure>
</section>
<section title="Shapes">
<t>
Shape data is used to represent regions of uncertainty for the reference and relative
locations. Shape data in the reference location uses a <xref target="WGS84">WGS84</xref> CRS.
Shape data in the relative location uses a relative CRS.
</t>
<t>
The XML form for shapes uses Geography Markup Language (GML) <xref
target="OGC.GML-3.1.1"/>, consistent with the rules in <xref target="RFC5491"/>.
Reference locations use the CRS URNs specified in <xref target="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.
</t>
<t>
The binary form of each shape uses a different shape type for 2d and 3d shapes.
</t>
<t>
Nine shape type codes are defined.
</t>
<section anchor="geo-point" title="Point">
<t>
A point "shape" describes a single point with unknown uncertainty. It consists of a
single set of coordinates.
</t>
<t>
In a two-dimensional CRS, the coordinate includes two values; in a three-dimensional
CRS, the coordinate includes three values.
</t>
<section title="XML encoding">
<figure title="GML Point Template">
<preamble>A point is represented in GML using the following template:</preamble>
<artwork><![CDATA[
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point>
]]></artwork>
</figure>
<t>
Where <spanx style="verb">$CRS-URN$</spanx> is replaced by a
urn:ietf:params:geopriv:relative:2d or urn:ietf:params:geopriv:relative:3d and <spanx
style="verb">$Coordinate-3$</spanx> is omitted if the CRS is two-dimensional.</t>
</section>
<section title="TLV encoding">
<t>
The point shape is introduced by a TLV of 113 for a 2D point and 114 for a 3D point.
</t>
<figure title="Point Encoding">
<artwork><![CDATA[
+------+------+
| 113/4|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="geo-circle" title="Circle or Sphere Shape">
<t>
A circle or sphere describes a single point with a single uncertainty value in meters.
</t>
<t>
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.
</t>
<section title="XML encoding">
<figure title="GML Circle Template">
<preamble>A circle is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Circle>
]]></artwork>
</figure>
<figure title="GML Sphere Template">
<preamble>A sphere is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:Sphere xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Sphere>
]]></artwork>
</figure>
</section><section title="TLV encoding">
<t>
A circular shape is introduced by a type code of 115. A spherical shape is introduced by a
type code of 116.</t>
<figure title="Circle or Sphere Encoding">
<artwork><![CDATA[
+------+------+
| 115/6|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
| Radius |
+------+------+------+------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="geo-ellipse" title="Ellipse or Ellipsoid Shape">
<t>
A ellipse or ellipsoid describes a point with an elliptical or ellipsoidal uncertainty
region.
</t>
<t>
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.
</t>
<section title="XML encoding">
<figure title="GML Ellipse Template">
<preamble>An ellipse is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipse>
]]></artwork>
</figure>
<figure title="GML Ellipsoid Template">
<preamble>An ellipsoid is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipsoid>
]]></artwork>
</figure>
</section>
<section title="TLV encoding">
<t>
An ellipse is introduced by a type code of 117 and an ellipsoid is introduced by a type code
of 118.</t>
<figure title="Ellipse or Ellipsoid Encoding">
<artwork><![CDATA[
+------+------+
| 117/8|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="geo-polygon" title="Polygon or Prism Shape">
<t>
A polygon or prism include a number of points that describe the outer boundary of an
uncertainty region. A prism also includes an altitude for each point and prism height.
</t>
<t>
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.
</t>
<section title="XML Encoding">
<figure title="GML Polygon Template">
<preamble>A polygon is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
]]></artwork>
</figure>
<t>
Alternatively, a series of <spanx style="verb">pos</spanx> elements can be used in place
of the single <spanx style="verb">posList</spanx>. Each <spanx style="verb">pos</spanx>
element contains two or three coordinate values.
</t>
<t>
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.
</t>
<t>
A GML polygon that includes altitude cannot be represented perfectly in TLV form. When
converting to the binary representation, a two dimensional CRS is used and altitude is
removed from each coordinate.
</t>
<figure title="GML Prism Template">
<preamble>A prism is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$
$Coordinate2-1$ ... ...
...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$
</gs:height>
</gs:Prism>
]]></artwork>
</figure>
<t>
Alternatively, a series of <spanx style="verb">pos</spanx> elements can be used in place
of the single <spanx style="verb">posList</spanx>. Each <spanx style="verb">pos</spanx>
element contains three coordinate values.
</t>
</section><section title="TLV Encoding">
<t>
A polygon containing 2D points uses a type code of 119. A polygon with 3D points uses
a type code of 120. A prism uses a type code of 121. The number of points can be
inferred from the length of the TLV.
</t>
<figure title="Polygon or Prism Encoding">
<artwork><![CDATA[
+------+------+
|119-21|Length|
+------+------+------+------+
| (3D-only) Height |
+------+------+------+------+
| Coordinate1-1 |
+------+------+------+------+
| Coordinate1-2 |
+------+------+------+------+
| (3D-only) Coordinate1-3 |
+------+------+------+------+
| Coordinate2-1 |
+------+------+------+------+
...
+------+------+------+------+
| CoordinateN-1 |
+------+------+------+------+
| CoordinateN-2 |
+------+------+------+------+
| (3D-only) CoordinateN-3 |
+------+------+------+------+
]]></artwork>
</figure>
<t>
Note that unlike the polygon representation in GML, the first and last points are not
the same point in the TLV representation. The duplicated point is removed from the
binary form.
</t>
</section>
</section>
<section anchor="geo-arc-band" title="Arc-Band Shape">
<t>
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.
</t>
<t>
Distance and angular measures are defined in meters and degrees respectively. Both are
encoded as single precision floating point values.
</t>
<section title="XML encoding">
<figure title="GML Arc-Band Template">
<preamble>An arc-band is represented in and converted from GML using the following
template:</preamble>
<artwork><![CDATA[
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$
</gs:openingAngle>
</gs:ArcBand>
]]></artwork>
</figure>
</section><section title="TLV Encoding">
<t>
An arc-band is introduced by a type code of 122.</t>
<figure title="Arc-Band Encoding">
<artwork><![CDATA[
+------+------+
| 122 |Length|
+------+------+------+------+
| Coordinate |
+------+------+------+------+
| Coordinate |
+------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Dynamic Location TLVs">
<t>
Dynamic location elements use the definitions in <xref target="RFC5962"/>.</t>
<section title="Orientation">
<t>
The orientation of the target is described using one or two angles. Orientation uses a type code of 123.</t>
<figure title="Dynamic Orientation TLVs">
<artwork><![CDATA[
+------+------+
| 123 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
]]></artwork>
</figure>
</section>
<section title="Speed">
<t>
The speed of the target is a scalar value in meters per second. Speed uses a type code of 124. </t>
<figure title="Dynamic Speed TLVs">
<artwork><![CDATA[
+------+------+
| 124 |Length|
+------+------+------+------+
| Speed |
+------+------+------+------+
]]></artwork>
</figure>
</section><section title="Heading">
<t>
The heading, or direction of travel, is described using one or two angles. Heading uses a type code of 125.</t>
<figure title="Dynamic Heading TLVs">
<artwork><![CDATA[
+------+------+
| 125 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="map" title="Secondary Map Metadata">
<t>
The optional "map" URL can be used to provide a user of relative location with a visual
reference for the location information. This document does not describe how the recipient uses
the map nor how it locates the reference or offset within the map. Maps can be simple images,
vector files, 2-D or 3-D geospatial databases, or any other form of representation understood by
both the sender and recipient.
</t>
<section anchor="map-url" title="Map URL">
<t>
In XML, the map is a <map> element defined within <relative-location> and contains
the URL. The URL is encoded as a UTF-8 encoded string. An <spanx style="verb">http:</spanx>
or <spanx style="verb">https:</spanx> URL MUST be used unless the entity creating the PIDF-LO
is able to ensure that authorized recipients of this data are able to use other URI schemes.
A "type" attribute MUST be present and specifies the kind of map the URL points to. Map types
are specified as MIME media types as recorded in the IANA Media Types registry. For example
<map type="image/png">https://www.example.com/floorplans/123South/floor-2</map>.
</t>
<t>
In binary, the map type is a separate TLV from the map URL. The media type uses a type code
of 126; the URL uses a type code of 127.
</t>
<figure title="Map URL TLVs">
<artwork><![CDATA[
+------+------+------+------+------+-- --+------+
| 126 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+
| 127 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+
]]></artwork>
</figure>
<t>
Note that the binary form restricts data to 255 octets. This restriction could be problematic
for URLs in particular. Applications that use the XML form, but cannot guarantee that a
binary form won't be used, are encouraged to limit the size of the URL to fit within this
restriction.
</t>
</section>
<section anchor="map-crs" title="Map Coordinate Reference System">
<t>
The CRS used by the map depends on the type of map. For example, a map described by a 3-D
geometric model of the building may contain a complete CRS description in it. For some kinds
of maps, typically described as images, the CRS used within the map must define the following:
<list style="symbols">
<t>
The CRS origin</t>
<t>
The CRS axes used and their orientation</t>
<t>
The unit of measure used</t>
</list>
</t>
<t>
This document provides elements that allow for a mapping between the local coordinate
reference system used for the relative location and the coordinate reference system used for
the map where they are not the same.
</t>
<section anchor="map-ref" title="Map Reference Point Offset">
<t>
This optional element identifies the coordinates of the reference point as it appears in the
map. This value is measured in a map-type dependent manner, using the coordinate system of
the map.
</t>
<t>
For image maps, coordinates start from the upper left corner and coordinates are first
counted by column with positive values to the right; then rows are counted with positive
values toward the bottom of the image. For such an image, the first item is columns, the
second rows and any third value applies to any third dimension used in the image coordinate
space.
</t>
<figure title="Map Reference Point Example XML">
<preamble>
The <offset> element contains 2 (or 3) coordinates similar to a GML <spanx
style="verb">pos</spanx>. For example:
</preamble>
<artwork><![CDATA[
<offset> 2670.0 1124.0 1022.0</offset>
]]></artwork>
</figure>
<t>
The map referenc point uses a type code of 129.
</t>
<figure title="Map Reference Point Coordinates TLV">
<artwork><![CDATA[
+------+------+
| 129 |Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
]]></artwork>
</figure>
<t>
If omitted, a value containing all zeros is assumed. If the coordinates provided contain fewer
values than are needed, the first value from the set is applied in place of any missing values.
</t>
</section>
<section anchor="map-orientation" title="Map Orientation">
<t>
The map orientation includes the orientation of the map direction in relation to the
Earth. Map orientation is expressed relative to the orientation of the relative
coordinate system. This means that map orientation with respect to WGS84 North is the
sum of the orientation field, plus any orientation included in a dynamic portion of the
reference location. Both values default to zero if no value is specified.
</t>
<t>
This type uses a single precision floating point value of degrees relative to North.
</t>
<t>
In XML, the <orientation> element contains a single floating point value, example
<orientation>67.00</orientation>. In TLV form map orientation uses the code
130:
</t>
<figure title="Map Orientation TLV">
<artwork><![CDATA[
+------+------+------+------+------+------+
| 130 |Length| Angle |
+------+------+------+------+------+------+
]]></artwork>
</figure>
</section>
<section anchor="map-scale" title="Map Scale">
<t>
The optional map scale describes the relationship between the units of measure used in
the map, relative to the meters unit used in the relative coordinate system.
</t>
<t>
This type uses a sequence of <xref target="IEEE.754">IEEE 754</xref> single precision
floating point values to represent scale as a sequence of numeric values. The units of
these values are dependent on the type of map, and could for example be pixels per meter
for an image.
</t>
<t>
A scaling factor is provided for each axis in the coordinate system. For a
two-dimensional coordinate system, two values are included to allow for different
scaling along the x and y axes independently. For a three-dimensional coordinate
system, three values are specified for the x, y and z axes. Decoders can determine the
number of scaling factors by examining the length field.
</t>
<t>
Alternatively, a single scaling value MAY be used to apply the same scaling factor to
all coordinate components.
</t>
<t>
Images that use a rows/columns coordinate system often use a left-handed coordinate
system. A negative value for the y/rows-axis scaling value can be used to account for
any change in direction between the y-axis used in the relative coordinate system and
the rows axis of the image coordinate system.
</t>
<t>
In XML, the <scale> element MAY contain a single scale value, or MAY contain 2 (or 3)
values in XML list form. In TLV form, scale uses a type code of 131. The length of the TLV
determines how many scale values are present:
</t>
<figure title="Map Scale TLV">
<artwork><![CDATA[
+------+------+------+------+------+------+
| 131 |Length| Scale(s) ...
+------+------+------+------+------+------+
]]></artwork>
</figure>
</section> <!-- map-scale -->
</section> <!-- map-crs -->
<section title="Map Example">
<t>
An example of expressing a map is:</t>
<figure title="Map Example">
<artwork><![CDATA[
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
]]></artwork>
</figure>
</section> <!-- map example -->
</section> <!-- map -->
</section>
<section anchor="example" title="Examples">
<t>
The examples in this section combine elements from <xref target="RFC3863"/>, <xref
target="RFC4119"/>, <xref target="RFC4479"/>, <xref target="RFC5139"/>, and <xref
target="OGC.GeoShape"/>.
</t>
<section title="Civic PIDF with Polygon Offset">
<figure><artwork><![CDATA[
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<dm:device id="nesspc-1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
<ca:BLD>A</ca:BLD>
<ca:FLR>I</ca:FLR>
<ca:ROOM>113</ca:ROOM>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
<gml:pos>431.0 -733.0</gml:pos> <!--F-->
<gml:pos>431.0 -732.0</gml:pos> <!--E-->
<gml:pos>433.0 -731.0</gml:pos> <!--D-->
<gml:pos>434.0 -732.0</gml:pos> <!--C-->
<gml:pos>434.0 -733.0</gml:pos> <!--B-->
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
]]></artwork>
</figure>
</section><section title="Geo PIDF with Circle Offset">
<figure><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0
</gs:radius>
</gs:Circle>
<rel:relative-location>
<rel:reference>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</rel:reference>
<rel:offset>
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gs:radius>
</gs:Circle>
</rel:offset>
<rel:map>
<rel:url type="image/png">
https://www.example.com/flrpln/123South/flr-2
</rel:url>
<rel:offset>2670.0 1124.0 1022.0</rel:offset>
<rel:orientation>67.00</rel:orientation>
<rel:scale>10 -10</rel:scale>
</rel:map>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
]]></artwork>
</figure>
</section><section title="Civic TLV with Point Offset">
<figure><artwork><![CDATA[
+--------+-------------------------------------------------+
| Type | Value |
+--------+-------------------------------------------------+
| 0 | en |
| | |
| 1 | IL |
| | |
| 3 | Chicago |
| | |
| 34 | Wacker |
| | |
| 18 | Drive |
| | |
| 19 | 3400 |
| | |
| 112 | Reference |
| | |
| 25 | Building A |
| | |
| 27 | Floor 6 |
| | |
| 26 | Suite 213 |
| | |
| 28 | Reception Area |
| | |
| 115 | 100 70 |
| | |
| 126 | image/png |
| | |
| 127 | http://maps.example.com/3400Wacker/A6 |
| | |
| 129 | 0.0 4120.0 |
| | |
| 130 | 113.0 |
| | |
| 131 | 10.6 |
+--------+-------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="schema" title="Schema Definition">
<figure title="xml schema relative-location">
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL
'http://ietf.org/rfc/rfcXXXX.txt' with the URL of published
document and remove this note.]] -->
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:relative">
Relative Location for PIDF-LO
</xs:appinfo>
<xs:documentation source="http://ietf.org/rfc/rfcXXXX.txt">
This schema defines a location representation that allows for
the description of locations that are relative to another.
An optional map reference is also defined.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="relative-location" type="rel:relativeType"/>
<xs:complexType name="relativeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="reference" type="rel:referenceType"/>
<xs:element name="offset" type="rel:offsetType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="referenceType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="offsetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="gml:_Geometry"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="map" type="rel:mapType"/>
<xs:complexType name="mapType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="url" type="rel:mapUrlType"/>
<xs:element name="offset" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="orientation" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="scale" type="rel:doubleList"
minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="mapUrlType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="type" type="rel:mimeType"
default="application/octet-stream"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="mimeType">
<xs:restriction base="xs:token">
<xs:pattern value="[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+
/[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+([\t ]*;([\t ])*[!#$%&
'\*\+\-\.\dA-Z^_`a-z\|~]+=([!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+|
"([!#-\[\]-~]|[\t ]*|\\[\t !-~])*"))*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>
This document describes a data format. To a large extent, security properties of this depend on
how this data is used.</t>
<t>
Privacy for location data is typically important. Adding relative location may increase the
precision of the location, but does not otherwise alter its privacy considerations, which are
discussed in <xref target="RFC4119"/>.
</t>
<t>
The map URL provided in a relative location could accidentally reveal information if a Location
Recipient uses the URL to acquire the map. The coverage area of a map, or parameters of the URL
itself, could provide information about the location of a Target. In combination with other
information that could reveal the set of potential Targets that the Location Recipient has
location information for, acquiring a map could leak significant information. In particular, it
is important to note that the Target and Location Recipient are often the same entity.
</t>
<t>
Access to map URLs MUST be secured with <xref target="RFC5246">TLS</xref> (that is, restricting
the map URL to be an https URI), unless the map URL cannot leak information about the Target's
location. This restricts information about the map URL to the entity serving the map request.
If the map URL conveys more information about a target than a map server is authorized to
receive, that URL MUST NOT be included in the PIDF-LO.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<section title="Relative Location Registry">
<t>
This document creates a new registry called "Relative Location Parameters". As defined in
<xref target="RFC5226"/>, this registry operates under "IETF Review" rules.
</t>
<t>
The content of this registry includes:
<list style="hanging">
<t hangText="Relative Location Code:">
Numeric identifier, assigned by IANA.
</t>
<t hangText="Brief description:">
Short description identifying the meaning of the element.
</t>
<t hangText="Reference to published specification:">
A stable reference to an RFC which describes the value in sufficient detail so that
interoperability between independent implementations is possible.
</t>
</list>
</t>
<t>
Values requested to be assigned into this registry MUST NOT conflict with values assigned in
the CAtypes registry or vice versa, unless the IANA considerations section for the new value
explicitly overrides this prohibition and the document defining the value describes how
conflicting TLV codes will be interpreted by implementations. To ensure this, the CAtypes
entries are explicitly reserved in the initial values table below. Those reserved entries can
be changed, but only with caution as explained here.
</t>
<t>
The values defined are:
</t>
<figure>
<artwork><![CDATA[
+--------+----------------------------------------+-----------+
| RLtype | description | Reference |
+--------+----------------------------------------+-----------+
| 0-40 | RESERVED by CAtypes registry | this RFC |
| 128 | | & RFC4776 |
+--------+----------------------------------------+-----------+
| 111 | relative location reference | this RFC |
| 113 | relative location shape 2D point | this RFC |
| 114 | relative location shape 3D point | this RFC |
| 115 | relative location shape circular | this RFC |
| 116 | relative location shape spherical | this RFC |
| 117 | relative location shape elliptical | this RFC |
| 118 | relative location shape ellipsoid | this RFC |
| 119 | relative location shape 2D polygon | this RFC |
| 120 | relative location shape 3D polygon | this RFC |
| 121 | relative location shape prism | this RFC |
| 122 | relative location shape arc-band | this RFC |
| 123 | relative location dynamic orientation | this RFC |
| 124 | relative location dynamic speed | this RFC |
| 125 | relative location dynamic heading | this RFC |
| 126 | relative location map type | this RFC |
| 127 | relative location map URI | this RFC |
| 129 | relative location map coordinates | this RFC |
| 130 | relative location map angle | this RFC |
| 131 | relative location map scale | this RFC |
+--------+----------------------------------------+-----------+
]]></artwork>
</figure>
</section>
<section title="URN Sub-Namespace Registration">
<t>
This document registers a new XML namespace, as per the guidelines in <xref
target="RFC3688"/>).</t>
<figure><artwork><![CDATA[
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location</title>
</head>
<body>
<h1>Format for representing relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published
document and remove this note.]] -->
END
]]></artwork>
</figure>
</section>
<section title="XML Schema Registration">
<t>
This section registers an XML schema as per the procedures in
<xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation</t>
<t hangText="Registratant Contact:">IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net).</t>
<t hangText="Schema">The XML for this schema is the entirety of Section 6
of this document.</t>
</list>
</t>
</section>
<section title="Geopriv Identifiers Registry">
<t>
This section registers two URNs for use in identifying relative coordinate reference systems.
These are added to a new "Geopriv Identifiers" registry according to the procedures in Section
4 of <xref target="RFC3553"/>. The "Geopriv Identifiers" registry is entered under the
"Uniform Resource Name (URN) Namespace for IETF Use" category.
</t>
<t>
Registrations in this registry follow the <xref target="RFC5226">IETF Review</xref> policy.
<list style="hanging">
<t hangText="Registry name:">Geopriv Identifiers</t>
<t hangText="URN Prefix:">urn:ietf:params:geopriv:</t>
<t hangText="Specification:">RFCXXXX (this document)</t>
<t hangText="Respository:">[Editor/IANA note: please include a link to the registry
location.]</t>
<t hangText="Index value:">Values in this registry are URNs or URN prefixes that start with
the prefix <spanx style="verb">urn:ietf:params:geopriv:</spanx>. Each is registered
independently.</t>
</list>
</t>
<t>
Each registration in the "Geopriv Identifiers" registry requires the following information:
<list style="hanging">
<t hangText="URN">The complete URN that is used, or the prefix for that URN.</t>
<t hangText="Description:">A summary description for the URN or URN prefix.</t>
<t hangText="Specification:">A reference to a specification describing the URN or URN
prefix.</t>
<t hangText="Contact:">Email for the person or groups making the registration.</t>
<t hangText="Index value:">As described in <xref target="RFC3553"/>, URN prefixes that are
registered include a description of how the URN is constructed. This is not applicable for
specific URNs.</t>
</list>
</t>
<t>
The "Geopriv Identifiers" registry has two initial registrations, included in the following
sections.
</t>
<section title="Registration of Two-Dimentional Relative Coordinate Reference System URN">
<t>
This section registers the <spanx style="verb">urn:ietf:params:geopriv:relative:2d</spanx> URN
in the "Geopriv Identifiers" registry.
<list style="hanging">
<t hangText="URN">urn:ietf:params:geopriv:relative:2d</t>
<t hangText="Description:">A two-dimensional relative coordinate reference system</t>
<t hangText="Specification:">RFCXXXX (this document)</t>
<t hangText="Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson
(martin.thomson@skype.net).</t>
<t hangText="Index value:">N/A.</t>
</list>
</t>
</section>
<section title="Registration of Three-Dimentional Relative Coordinate Reference System URN">
<t>
This section registers the <spanx style="verb">urn:ietf:params:geopriv:relative:3d</spanx> URN
in the "Geopriv Identifiers" registry.
<list style="hanging">
<t hangText="URN">urn:ietf:params:geopriv:relative:3d</t>
<t hangText="Description:">A three-dimensional relative coordinate reference system</t>
<t hangText="Specification:">RFCXXXX (this document)</t>
<t hangText="Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson
(martin.thomson@skype.net).</t>
<t hangText="Index value:">N/A.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>
This is the product of a design team on relative location. Besides the authors, this team
included: Marc Linsner, James Polk, and James Winterbottom.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1014;
&RFC2119;
&RFC3553;
&RFC3688;
&RFC4119;
&RFC4776;
&RFC5139;
&RFC5226;
&RFC5246;
&RFC5491;
&RFC5962;
&RFC6225;
&RFC6848;
<reference anchor="OGC.GML-3.1.1" target="http://portal.opengeospatial.org/files/?artifact_id=4700">
<front>
<title>Geographic information - Geography Markup Language (GML)</title>
<author initials="S" surname="Cox" fullname="Simon Cox">
<organization />
</author>
<author initials="P" surname="Daisey" fullname="Paul Daisey">
<organization />
</author>
<author initials="R" surname="Lake" fullname="Ron Lake">
<organization />
</author>
<author initials="C" surname="Portele" fullname="Clemens Portele">
<organization />
</author>
<author initials="A" surname="Whiteside" fullname="Arliss Whiteside">
<organization />
</author>
<date month="April" day="19" year="2004" />
<abstract>
<t>
Geography Markup Language is an XML grammar written in XML Schema for the modelling,
transport, and storage of geographic information.
</t>
</abstract>
</front>
<seriesInfo name="OpenGIS" value="03-105r1" />
</reference>
<reference anchor="OGC.GeoShape">
<front>
<title abbrev="GeoShape">GML 3.1.1 PIDF-LO Shape Application Schema for use by the
Internet Engineering Task Force (IETF)</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
</author>
<author initials="C." surname="Reed" fullname="Carl Reed, PhD.">
<organization>Open Geospatial Consortium Inc.</organization>
</author>
<date month="April" day="10" year="2007"/>
</front>
<seriesInfo name="OGC Best Practice"
value="06-142r1, Version: 1.0"/>
</reference>
<reference anchor="IEEE.754">
<front>
<title abbrev="IEEE754">IEEE Standard for Binary Floating-Point Arithmetic</title>
<author>
<organization>IEEE</organization>
</author>
<date month="January" year="2003"/>
</front>
<seriesInfo name="IEEE Standard"
value="754-1985"/>
</reference>
<reference anchor="Clinger1990" target="ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps">
<front>
<title abbrev="Float">How to Read Floating Point Numbers Accurately</title>
<author initials="W." surname="Clinger" fullname="William D. Clinger">
<organization/>
</author>
<date month="" day="" year="1990"/>
</front>
<seriesInfo name="Proceedings of Conference on Programming Language Design and Implementation"
value="pp. 92-101"/>
</reference>
<reference anchor="WGS84" target="">
<front>
<title>
Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition
</title>
<author fullname="">
<organization>US National Imagery and Mapping Agency</organization>
</author>
<date day="3" month="January" year="2000"/>
</front>
<seriesInfo name="NIMA" value="TR8350.2"/>
<format type="TXT"
target="https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/WORLDGEODETICSYSTEM/Pages/default.aspx"/>
</reference>
</references>
<references title="Informative References">
&RFC3863;
&RFC4479;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:01:16 |