Relative Location Representation
Extracted elements (29)
A single timestamp in the PIDF-LO tuple applies to all three components of relative location (baseline, reference, and offset). This is intentional to ensure consistency when dynamic elements such as velocity or orientation are present; the location generator is responsible for keeping all fields temporally coherent.
The baseline location is kept outside the <relative-location> element so that clients not understanding relative location still receive a usable (if less precise) location. The baseline is intended to encompass both the reference and offset regions, not to pinpoint the reference point itself.
TLV type codes for relative location parameters are constrained to avoid overlap with the Civic Address Types (CAtypes) registry, enabling both location reference TLVs and relative offset TLVs to coexist in a single binary object without type collisions.
A GML Polygon that includes altitude cannot be perfectly represented in TLV form. When converting to the binary representation, a two-dimensional CRS is used and altitude is dropped from each coordinate.
In the GML (XML) polygon representation, the first point is repeated at the end of the coordinate sequence to close the ring, but in the TLV binary representation the closing duplicate is removed; decoders must account for this difference when converting between the two forms.
The binary TLV Length field is an 8-bit integer limited to 255 octets. This can be problematic for map URLs; applications using the XML form but that may interoperate with a binary decoder are encouraged to keep map URLs within 255 bytes.
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.
Access to map URLs MUST be secured with TLS (i.e., the map URL must be an https URI) unless the map URL cannot leak information about the Target's location. 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.
An 'http:' or 'https:' URL MUST be used for the map URL unless the PIDF-LO creator can ensure that authorized recipients can use other URI schemes. A 'type' attribute MUST be present on the map URL element, specifying the MIME media type of the map document.
At least 3 points MUST be included in a polygon shape. For interoperability with existing systems, an encoding SHOULD include 15 or fewer points unless the recipient is known to support larger numbers.
If the baseline location is expressed as a geodetic location, the reference MUST be geodetic. If the baseline is a civic address, the reference MUST be civic.
Location objects SHOULD NOT have all location information in the baseline location, as this would cause clients that do not understand relative location to incorrectly interpret the reference point as the actual precise location of the client.
More than one relative shape MUST NOT be included in either a PIDF-LO or TLV encoding of location for a given reference point.
A relative location is composed of three parts: a baseline location (expressed as a normal PIDF-LO location-info element), a reference location (a refinement of the baseline serving as the origin), and an offset (a shape in meters using a Cartesian coordinate system relative to the reference).
The relative coordinate system uses a Cartesian CRS with the reference location as origin. The x-axis points East, the y-axis points North, and the optional z-axis points Up, all in meters. Dynamic location elements (orientation, speed, heading) in the reference can rotate and translate the coordinate system.
This document creates the 'Geopriv Identifiers' registry under the URN prefix 'urn:ietf:params:geopriv:' with IETF Review policy, and registers two initial URNs: 'urn:ietf:params:geopriv:relative:2d' and 'urn:ietf:params:geopriv:relative:3d' for the two- and three-dimensional relative CRS identifiers used in GML srsName attributes.
This document creates the 'Relative Location Parameters' registry (RLtype codes) under IETF Review policy, sharing a page with the 'Civic Address Types (CAtypes)' registry. Initial assignments include type codes 111, 113–127, 129–131 for reference, shapes, dynamic elements, and map metadata. Codes 0–40 and 128 are reserved to prevent collisions with CAtypes.
This document registers the XML namespace URN 'urn:ietf:params:xml:ns:pidf:geopriv10:relative' and the XML schema URN 'urn:ietf:params:xml:schema:pidf:geopriv10:relative' in the IETF XML Registry per RFC 3688.
Adding a relative location may increase the precision of the location information but does not otherwise alter the existing privacy considerations for PIDF-LO data, which remain governed by RFC 4119.
The map URL provided in a relative location could inadvertently reveal Target location information. The coverage area of the map or parameters in the URL itself could disclose location when acquired by a Location Recipient, particularly combined with knowledge of the set of potential Targets.
All coordinate, distance, and angle values in the binary form are encoded as IEEE 754 single-precision 32-bit floating-point (sign, 8 exponent bits, 23 fractional bits), most-significant bit first. When a value cannot be exactly represented, the best approximation MUST be selected per Clinger (1990).
Arc-band shape (2D only) uses type code 122 and encodes two coordinates, Inner Radius, Outer Radius, Start Angle, and Opening Angle as 32-bit IEEE 754 floats; distances in meters, angles in degrees.
Dynamic location TLVs: Orientation (type 123) carries one or two angle values; Speed (type 124) carries a scalar in meters per second; Heading (type 125) carries one or two angles. All values are single-precision IEEE 754 floats.
Ellipse (type 117) and Ellipsoid (type 118) TLVs encode coordinates, semi-major axis, semi-minor axis, orientation, and (for 3D) semi-vertical axis, all as 32-bit IEEE 754 floats.
Map metadata TLVs: map media type (type 126) and map URL (type 127) are variable-length UTF-8 strings; map reference point coordinates (type 129); map orientation angle (type 130, single 32-bit float); map scale (type 131, one to three 32-bit floats). The binary form restricts all values to 255 octets maximum.
Point shapes use TLV type 113 (2D) or 114 (3D); each coordinate is a 32-bit IEEE 754 float. Circle/Sphere shapes use type 115 (circle) or 116 (sphere), adding a Radius field after the coordinates.
Polygon TLVs use type 119 (2D points) or 120 (3D points); Prism uses type 121 with an optional Height field prepended. The number of points is inferred from the TLV length. Unlike GML, the first and last points are not duplicated in the TLV representation.
The binary TLV format uses an 8-bit unsigned integer Type field (T) and an 8-bit unsigned integer Length field (N, encoding 0–255 bytes of value). Type codes in the Relative Location Parameters registry must not conflict with Civic Address Types (CAtypes) registry values.
The Reference TLV uses type code 111 and contains nested civic or geo TLVs corresponding to the reference location type (civic or geodetic), combining both baseline and reference locations in a single container.