| GEOPRIV | M. Thomson |
| Internet-Draft | Andrew Corporation |
| Intended status: Standards Track | B. Rosen |
| Expires: September 29, 2011 | Neustar |
| D. Stanley | |
| Aruba Networks | |
| G. Bajko | |
| Nokia | |
| A. Thomson | |
| Cisco Systems, Inc. | |
| March 28, 2011 |
Relative Location Representation
This document defines an extension to PIDF-LO (RFC4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system to allow display of the map with the reference point and the relative offset. Also included in this document is a Type/Length/Value (TLV) representation of the relative location for use in other protocols that use TLVs.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes a format for the expression of relative location information.
A relative location is formed of a reference location, plus a relative offset from that reference location. The reference location can be represented in either civic or geodetic form. The reference location can also have dynamic components such as velocity. The relative offset is specified in meters using a Cartesian coordinate system.
In addition to the relative location, an optional URI can be provided to a document that contains a map, floorplan or illustration. Applications could use this information to display the relative location. Additional fields allow the map to be oriented and scaled correctly.
Two formats are included: an XML form that is intended for use in PIDF-LO [RFC4119] and a TLV format for use in other protocols such as those that already convey binary representation of location information defined in [RFC4776].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document describes an extension to PIDF-LO [RFC4119] as updated by [RFC5139] and [RFC5491], to allow the expression of a location as an offset relative to a reference.
This extension effectively allows the creator of a location object to include two location values plus an offset. The "baseline" location that is given outside of the <relative-location> element is what will be visible to a client that does not understand that extension (i.e., one that ignores the <relative-location> element). A client that does understand this extension will interpret the location within the relative element as a refinement of the baseline location, which gives the reference location for the relative offset.
Creators of location objects with relative location thus have a choice of how much information to put into the "baseline" location and how much to put into the "reference" location. For example, all location information could be put inside the <relative-location> element, so that clients that do not understand relative location would receive no location information at all. Alternatively, the baseline location value could be precise enough to specify a building that contains the relative location, and the reference location could specify a point within the building from which the offset is measured.
The baseline location SHOULD be general enough to describe both the reference location and the relative location (reference plus offset). In particular, while it is possible to put all location information into the "reference" location (leaving an universally broad "baseline"), location objects SHOULD NOT have all location information in the baseline location. Doing this would cause clients that do not understand relative location to incorrectly interpret the baseline location (i.e., the reference point) as the actual, precise location of the client.
Both the baseline and the reference location are defined either as a geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If the baseline location was expressed as a geodetic location, the reference MUST be geodetic. If the baseline location was expressed as a civic address, the reference MUST be a civic.
Baseline and reference locations MAY also include dynamic location information [RFC5962].
The relative location can be expressed using a point (2- or 3-dimensional), or a shape that includes uncertainty: circle, sphere, ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of these shapes can be found in [RFC5491].
Optionally, a reference to a 'map' document can be provided. The reference is a URI. The document could be an image or dataset that represents a map, floorplan or other form. The type of document the URI points to is described as a MIME media type. Metadata in the relative location can include the location of the reference point in the map as well as an orientation (angle from North) and scale to align the document CRS with the WGS-84 CRS. The document is assumed to be useable by the application receiving the PIDF with the relative location to locate the reference point in the map. This document does not describe any mechanisms for displaying or manipulating the document other than providing the reference location, orientation and scale.
As an example, consider a relative location expressed as a point, relative to a civic location:
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:relative@example.com">
<dm:device id="relative1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:INT N="Door" R="A">Front</ca:INT>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos>
</gml:Point>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
<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>
Relative location is a shape (point, circle, ellipse…). The shape is defined with a CRS that has a datum defined as the reference (which appears as a civic address or geodetic location in the tuple), and the shape coordinates as meter offsets North/East of the datum measured in meters (with an optional Z offset relative to datum altitude). An optional angle allows the reference CRS be to rotated with respect to North.
The relative coordinate reference system uses a coordinate system with two or three axes.
The baseline and reference locations are used to define a relative datum. The reference location defines the origin of the coordinate system. The centroid of the reference location is used when the reference location contains any uncertainty.
The axes in this coordinate system are originally oriented based on the directions of East, North and Up from the reference location: the first (x) axis increases to the East, the second (y) axis points North, and the optional third (z) axis points Up. All axes of the coordinate system use meters as a basic unit.
Any coordinates in the relative shapes use the described Cartesian coordinate system. In the XML form, this uses a URN of “urn:ietf:params:geopriv:relative:2d” for two-dimensional shapes and “urn:ietf:params:geopriv:relative:3d” for three-dimensional shapes. The binary form uses different shape type identifiers for 2D and 3D shapes.
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.
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 shape elements described below.
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 ...
+------+------+------+------+------+------+------+
Type field (X) is defined as a single byte. The type codes used are registered an IANA managed 'RLtypes' registry defined by this document, and restricted to not include the values defined by the CAtypes registry. This restriction permits a location reference and offset to be coded with unique TLVs.
The Length field (N) is defined as an unsigned integer that is one byte in length. This field can encode values from 0 to 255. The length field describes the number of bytes in the Value. Length does not count the bytes used for the Type or Length.
The Value field is defined separately for each type.
Each element of the relative location has a unique TLV assignment. A relative location encoded in TLV would have the baseline location TLVs, 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.
All distance measures used in shapes are expressed in meters.
All orientation angles used in shapes are expressed in degrees. Orientation angles are measured from WGS84 Northing to Easting with zero at Northing. Orientation angles in the relative coordinate system start from the second coordinate axis (y or Northing) and increase toward the first axis (x or Easting).
The binary form uses single-precision floating point values [IEEE754] to represent coordinates, distance and angle measures. Single precision values are 32-bit values with a sign bit, 8 exponent bits and 23 fractional bits.
Binary-encoded coordinate values are considered to be a single value without uncertainty. When encoding a value that cannot be exactly represented, the best approximation is chosen according to [Clinger1990].
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.
Baseline TLVs are defined in [RFC3825].
When a reference is encoded in binary form, the baseline and reference locations are combined in a reference TLV. This TLV contains civic address TLVs (if the baseline was a civic) or geo TLVs (if the baseline was a geo).
+------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
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)
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.
A point "shape" describes a single point with unknown uncertainty. It consists of a single set of coordinates.
In a two-dimensional CRS, the coordinate includes two values; in a three-dimensional CRS, the coordinate includes three values.
A point is represented in GML using the following template:
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point>
Where $CRS-URN$ is replaced by a urn:ietf:params:geopriv:relative:2d or urn:ietf:params:geopriv:relative:3d and $Coordinate-3$ is omitted if the CRS is two-dimensional.
The point shape is introduced by a TLV of 113 for a 2D point and 114 for a 3D point.
+------+------+ | 113/4|Length| +------+------+------+------+ | Coordinate-1 | +------+------+------+------+ | Coordinate-2 | +------+------+------+------+ | (3D-only) Coordinate-3 | +------+------+------+------+
A circle or sphere describes a single point with a single uncertainty value in meters.
In a two-dimensional CRS, the coordinate includes two values and the resulting shape forms a circle. In a three-dimensional CRS, the coordinate includes three values and the resulting shape forms a sphere.
A circle is represented in and converted from GML using the following template:
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Circle>
A sphere is represented in and converted from GML using the following template:
<gs:Sphere xmlns:gml="http://www.opengis.net/gml"
xmlns:gml="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>
A circular shape is introduced by a type code of 115. A spherical shape is introduced by a type code of 116.
+------+------+ | 115/6|Length| +------+------+------+------+ | Coordinate-1 | +------+------+------+------+ | Coordinate-2 | +------+------+------+------+ | (3D-only) Coordinate-3 | +------+------+------+------+ | Radius | +------+------+------+------+
A ellipse or ellipsoid describes a point with an elliptical or ellipsoidal uncertainty region.
In a two-dimensional CRS, the coordinate includes two values, plus a semi-major axis, a semi-minor axis, a semi-major axis orientation (clockwise from North). In a three-dimensional CRS, the coordinate includes three values and in addition to the two-dimensional values, an altitude uncertainty (semi-vertical) is added.
An ellipse is represented in and converted from GML using the following template:
<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>
An ellipsoid is represented in and converted from GML using the following template:
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipsoid>
An ellipse is introduced by a type code of 117 and an ellipsoid is introduced by a type code of 118.
+------+------+ | 117/8|Length| +------+------+------+------+ | Coordinate-1 | +------+------+------+------+ | Coordinate-2 | +------+------+------+------+ | (3D-only) Coordinate-3 | +------+------+------+------+------+------+------+------+ | Semi-Major Axis | Semi-Minor Axis | +------+------+------+------+------+------+------+------+ | Orientation | (3D) Semi-Vertical Axis | +------+------+------+------+------+------+------+------+
A polygon or prism include a number of points that describe the outer boundary of an uncertainty region. A prism also includes an altitude for each point and prism height.
At least 3 points MUST be included in a polygon. In order to interoperate with existing systems, an encoding SHOULD include 15 or fewer points, unless the recipient is known to support larger numbers.
A polygon is represented in and converted from GML using the following template:
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
Alternatively, a series of pos elements can be used in place of the single posList. Each pos element contains two or three coordinate values.
Note that the first point is repeated at the end of the sequence of coordinates and no explicit count of the number of points is provided.
A GML polygon that includes altitude cannot be represented completely in binary. When converting to the binary representation, a two dimensional CRS is used and altitude is removed from each coordinate.
A prism is represented in and converted from GML using the following template:
<gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$
$Coordinate2-1$ ... ...
...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$
</gs:height>
</gs:Prism>
Alternatively, a series of pos elements can be used in place of the single posList. Each pos element contains three coordinate values.
A polygon containing 2D points is 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.
+------+------+ |119-21|Length| +------+------+------+------+------+------+ | Count | (3D-only) Height | +------+------+------+------+------+------+ | Coordinate1-1 | +------+------+------+------+ | Coordinate1-2 | +------+------+------+------+ | (3D-only) Coordinate1-3 | +------+------+------+------+ | Coordinate2-1 | +------+------+------+------+ ... +------+------+------+------+ | CoordinateN-1 | +------+------+------+------+ | CoordinateN-2 | +------+------+------+------+ | (3D-only) CoordinateN-3 | +------+------+------+------+
Note that unlike the polygon representation in GML, the first and last points are not the same point to be the same in the TLV representation. The duplicated point is removed from the binary form.
A arc-band describes a region constrained by a range of angles and distances from a predetermined point. This shape can only be provided for a two-dimensional CRS.
Distance and angular measures are defined in meters and degrees respectively. Both are encoded as single precision floating point values.
An arc-band is represented in and converted from GML using the following template:
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$
</gs:openingAngle>
</gs:Ellipsoid>
An arc-band is introduced by a type code of 122.
+------+------+ | 122 |Length| +------+------+------+------+ | Coordinate | +------+------+------+------+ | Coordinate | +------+------+------+------+------+------+------+------+ | Inner Radius | Outer Radius | +------+------+------+------+------+------+------+------+ | Start Angle | Opening Angle | +------+------+------+------+------+------+------+------+
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.
In XML, the map is a <map> element defined within <relative-location> and contains the URL. The URL is encoded as a UTF-8 encoded string. An http: or https: URL MUST be used unless the entity creating the PIDF-LO is able to ensure that authorized recipients of this data are able to use other URI schemes. A "type" attribute MUST be present and specifies the kind of map the URL points to. Map types are specified as mime media types as recorded in the IANA Media Types registry. For example <map type="image/png">https://www.example.com/floorplans/123South/floor-2</map>. In binary, the map type is a separate TLV from the map URL:
+------+------+------+------+------+-- --+------+
| 123 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+
| 124 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+
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:
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.
This optional element identifies the coordinates of the reference point as it appears in the map. This value is measured in a map-type dependent manner, using the coordinate system of the map.
For image maps, coordinates start from the upper left corner and coordinates are first counted by column with positive values to the right; then rows are counted with positive values toward the bottom of the image. For such an image, the first item is columns, the second rows and any third value applies to any third dimension used in the image coordinate space.
The <offset> element contains 2 (or 3) coordinates similar to a GML pos, For example:
<offset> 2670.0 1124.0 1022.0</offset>
+------+------+
| 125 |Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
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.
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 th orientation field, plus any orientation included in a dynamic portion of the reference location. Both values default to zero if no value is specified.
This type uses a single precision floating point value of degrees relative to North.
In XML, the <orientation> element contains a single floating point value, example <orientation>67.00</orientation>. In TLV form:
+------+------+------+------+------+------+
| 126 |Length| Angle |
+------+------+------+------+------+------+
The optional map scale describes the relationship between the units of measure used in the map, relative to the meters unit used in the relative coordinate system.
This type uses a sequence of IEEE 754 [IEEE.754] single precision floating point values to represent scale as a sequence of numeric values. The units of these values is dependent on the type of map, and could for example be pixels per meter for an image.
A scaling factor is provided for each axis in the coordinate system. For a two-dimensional coordinate system, two values are included to allow for different scaling along the x and y axes independently. For a three-dimensional coordinate system, three values are specified for the x, y and z axes.
Alternatively, a single scaling value MAY be used to apply the same scaling factor to all coordinate components.
Images that use a rows/columns coordinate system often use a left-handed coordinate system. A negative value for the y/rows-axis scaling value can be used to account for any change in direction between the y-axis used in the relative coordinate system and the rows axis of the image coordinate system.
In XML, the <scale> element may contain the single scale value, or may contain 2 (or 3) values similar to a GML pos with separate scale values. In TLV form:
+------+------+------+------+------+
| 127 |Length| Scales ...
+------+------+------+------+------+
An example of expressing a map is:
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<dm:device id="nesspc-1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:INT N="Building">A</ca:INT>
<ca:INT N="Level">I</ca:INT>
<ca:INT N="Suite">113</ca:INT>
<ca:INT N="Door" R="A">Front</ca:INT>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
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>
<?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"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<gp:geopriv>
<gp:location-info>
<gml: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>
</gml: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>
<gml:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gml:radius>
</gml:Circle>
</rel:relative-location>
<map:map>
<map:urltype="image/png">
https://www.example.com/flrpln/123South/flr-2</gp:url>
<map:offset> 2670.0 1124.0 1022.0</gp:offset>
<map:orientation>67.00</gp:orientation>
<map:scale>10</gp:scale>
</map:map>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
+--------+-------------------------------------------------+
| Type | Value |
+--------+-------------------------------------------------+
| 0 | en |
| | |
| 1 | IL |
| | |
| 3 | Chicago |
| | |
| 34 | Wacker |
| | |
| 18 | Drive |
| | |
| 19 | 3400 |
| | |
| 112 | Reference |
| | |
| 40 | BBuilding|A |
| | |
| 40 | AFloor|6th |
| | |
| 40 | BSuite|213 |
| | |
| 40 | ADoor|Front |
| | |
| 115 | 100 70 |
| | |
| 123 | image/png |
| | |
| 124 | http://maps.example.com/3400Wacker/A6 |
| | |
| 125 | 0.0 4120.0 |
| | |
| 126 | 113.0 |
| | |
| 127 | 10.6 |
+--------+-------------------------------------------------+
<?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>
<!-- From draft-ietf-httpbis-p3-payload-09, excluding
the obsolete parts -->
<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>
This document describes a data format. To a large extent, security properties of this depend on how this data is used.
Privacy for location data is typically important. Adding relative location may increase the precision of the location, but does not otherwise alter its privacy considerations, which are discussed in [RFC4119]
[[Not that interesting, but it could be relevant ?]] The fractional bits in IEEE 754 [IEEE.754] floating point values can be used as a covert channel. For values of either zero or infinity, non-zero fraction bits could be used to convey information. If the presence of covert channels is not desired then the fractional bits MUST be set to zero. There is no need to represent NaN (not a number) in this encoding.
This document creates a new registry called ’Relative Location Parameters’. As defined in [RFC5226], this registry operates under "IETF Consensus" rules.
The content of this registry includes:
Relative Location Code: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the element.
Reference to published specification: A stable reference to an RFC which describes the value in sufficient detail so that interoperability between independent implementations is possible.
IANA is requested to not permit values to be assigned into this registry which conflict with values assigned in the CAtypes registry or to permit values to be assigned into the CAtypes registry which conflict with values assigned to to this registry unless the IANA considerations section for the new value explicitly overrides this prohibition, and the document defining the value describes how conflicting TLV codes will be interpreted by implementations
The values defined are:
+--------+----------------------------------------+-----------+ | RLtype | description | Reference | +--------+-------+--------------------------------+-----------+ | 111 | relative location reference | this RFC | | 112 | relative location angle | 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 arc-band | 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 | | 122 | relative location map type | this RFC | | 123 | relative location map URI | this RFC | | 124 | relative location map coordinates | this RFC | | 125 | relative location map angle | this RFC | | 126 | relative location map scale | this RFC | +--------+-------+--------------------------------+-----------+
This document registers a new XML namespace, as per the guidelines in [RFC3688]) that has been registered with IANA.
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
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 in GEOPRIV</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
This section registers an XML schema as per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
The XML for this schema can be found as the entirety of Section 7
of this document.
This section registers two public identifiers as per the procedures in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location 2d CRS</title>
</head>
<body>
<h1>Identifier for a 2D CRS in GEOPRIV relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published document
and remove this note.]] -->
END
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location 3d CRS</title>
</head>
<body>
<h1>Identifier for a 3D CRS in GEOPRIV relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published
document and remove this note.]] -->
END
This is the product of a design team on relative location. Besides the authors, this team included: Marc Linsner, James Polk, and James Winterbottom.
| [RFC3688] | Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |