idnits 2.17.1 draft-thomson-geopriv-relative-location-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2010) is 5078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3986' is defined on line 1420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clinger1990' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Andrew Corporation 4 Intended status: Standards Track B. Rosen 5 Expires: November 26, 2010 Neustar 6 D. Stanley 7 Aruba Networks 8 G. Bajko 9 Nokia 10 A. Thomson 11 Cisco Systems, Inc. 12 May 25, 2010 14 Relative Location Representation 15 draft-thomson-geopriv-relative-location-01 17 Abstract 19 This document defines an extension to PIDF-LO (RFC4119) for the 20 expression of location information that is defined relative to a 21 reference point. The reference point may be expressed as a geodetic 22 or civic location, and the relative offset may be one of several 23 shapes. Optionally, a reference to a secondary document (such as a 24 map image) can be included, along with the relationship of the map 25 coordinate system to the reference/offset coordinate system to allow 26 display of the map with the reference point and the relative offset. 27 Also included in this document is a Type/Length/Value (TLV) 28 representation of the relative location for use in other protocols 29 that use TLVs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 26, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions used in this document . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Orientation of Relative Offset Coordinate Reference 71 System . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Shape Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Units of Measure . . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Coordinates . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.3. On Uncertainty and Encoding . . . . . . . . . . . . . . . 10 76 7. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.1.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 10 79 7.1.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 10 80 7.2. Circle or Sphere Shape . . . . . . . . . . . . . . . . . . 11 81 7.2.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 11 82 7.2.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 12 83 7.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . . . . 12 84 7.3.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 13 85 7.3.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . 14 86 7.4. Polygon or Prism Shape . . . . . . . . . . . . . . . . . . 14 87 7.4.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . 15 88 7.4.2. TLV Encoding . . . . . . . . . . . . . . . . . . . . . 16 89 7.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . . . . 17 90 7.5.1. XML encoding . . . . . . . . . . . . . . . . . . . . . 18 91 7.5.2. TLV Encoding . . . . . . . . . . . . . . . . . . . . . 18 92 8. Secondary Map Metadata . . . . . . . . . . . . . . . . . . . . 18 93 8.1. Map URL . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8.2. Map Coordinate Reference System . . . . . . . . . . . . . 19 95 8.2.1. Map Reference Point Offset . . . . . . . . . . . . . . 19 96 8.2.2. Map Orientation . . . . . . . . . . . . . . . . . . . 20 97 8.2.3. Map Scale . . . . . . . . . . . . . . . . . . . . . . 21 98 8.3. Map Example . . . . . . . . . . . . . . . . . . . . . . . 22 99 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 9.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . . 22 101 9.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23 102 9.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25 103 10. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 106 12.1. Relative Location Registry . . . . . . . . . . . . . . . . 28 107 12.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 29 108 12.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30 109 12.4. CRS public identifier registration . . . . . . . . . . . . 30 110 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 111 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 113 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 115 1. Introduction 117 This document describes a format for the expression of relative 118 location information. 120 The location is given relative to a reference, which is expressed 121 with a civic or geodetic representation, with the relative offset as 122 described in this document. The offset is expressed in meters, and a 123 directional vector is either implied to be earth North/East or 124 supplied explicitly. Also defined is an optional URI to a document 125 that can contain a map/floorplan/illustration ('map') upon which the 126 relative location can be plotted as well as an optional angle, offset 127 and scale defining the Coordinate Reference System (CRS) of the map. 129 Two formats are included: an XML form that is intended for use in 130 PIDF-LO [RFC4119] and a TLV format for use in other protocols such as 131 those that already convey binary representation of location 132 information defined in [RFC4776]. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 Numeric values in this scheme are all represented using floating 141 point values [IEEE.754]. Single precision values are 32-bit values 142 with a sign bit, 8 exponent bits and 23 fractional bits. Double 143 precision values are 64-bit values with a sign bit, 11 exponent bits 144 and 52 fractional bits. 146 3. Overview 148 This document describes an update to PIDF-LO [RFC4119] as updated by 149 [RFC5139] and [RFC5491], to allow the expression of a location as an 150 offset relative to a reference. 152 This extension effectively allows the creator of a location object to 153 include two location values plus an offset. The "baseline" location 154 that is given outside of the element is what will 155 be visible to a client that does not understand that extension (i.e., 156 one that ignores the element). A client that 157 does understand this extension will interpret the location within the 158 relative element as a refinement of the baseline location, which 159 gives the reference location for the relative offset. 161 Creators of location objects with relative location thus have a 162 choice of how much information to put into the "baseline" location 163 and how much to put into the "reference" location. For example, all 164 location information could be put inside the 165 element, so that clients that do not understand relative location 166 would receive no location information at all. Alternatively, the 167 baseline location value could be precise enough to specify a building 168 that contains the relative location, and the reference location could 169 specify a point within the building from which the offset is 170 measured. 172 In any case, it is RECOMMENDED that the baseline location be general 173 enough to describe both the reference location and the relative 174 location (reference plus offset). In particular, while it is 175 possible to put all location information into the "reference" 176 location (leaving an universally broad "baseline"), location objects 177 SHOULD NOT have all location information in the baseline location. 178 Doing this would cause clients that do not understand relative 179 location to incorrectly interpret the baseline location (i.e., the 180 reference point) as the actual, precise location of the client. 182 Both the baseline and the reference location are defined either as a 183 geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If 184 the baseline location was expressed as a geodetic location, the 185 reference MUST be geodetic. If the baseline location was expressed 186 as a civic address, the reference MUST be a civic. 188 The relative location can be expressed using a point (2- or 189 3-dimensional), or a shape that includes uncertainty: circle, sphere, 190 ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of 191 these shapes can be found in [RFC5491]. 193 Optionally, a reference to a 'map' document can be provided. The 194 reference is a URI. The document could be an image or dataset that 195 represents a map, floorplan or other form. The type of document the 196 URI points to is described as a MIME media type. Metadata in the 197 relative location can include the location of the reference point in 198 the map as well as an orientation (angle from North) and scale to 199 align the document CRS with the WGS-84 CRS. The document is assumed 200 to be useable by the application receiving the PIDF with the relative 201 location to locate the reference point in the map. This document 202 does not describe any mechanisms for displaying or manipulating the 203 document other than providing the reference location, orientation and 204 scale. 206 As an example, consider a relative location expressed as a point, 207 relative to a civic location: 209 217 218 219 220 221 AU 222 NSW 223 Wollongong 224 North Wollongong 225 Flinders 226 Street 227 123 228 229 230 231 232 Front 233 234 235 236 238 100 50 239 240 241 242 243 244 GPS 245 246 247 http://example.com/location/map.png 248 249 20. 120. 250 29. 251 20. -20. 252 253 254 mac:1234567890ab 255 2007-06-22T20:57:29Z 256 257 259 4. Binary Format 261 This document describes a way to encode the relative location in a 262 binary TLV form for use in other protocols that use TLVs to represent 263 location. 265 A type-length-value encoding is used. 267 +------+------+------+------+------+------+------+------+ 268 | Type | Length | Value ... 269 +------+------+------+------+------+------+------+------+ 270 | X | N | Value label ... 271 +------+------+------+------+------+------+------+------+ 273 Figure 1: TLV-tuple format 275 Type field (X) is defined as a single byte. The type codes used are 276 registered an IANA managed 'RLtypes' registry defined by this 277 document, and restricted to not include the values defined by the 278 CAtypes registry. This restriction permits a location reference and 279 offset to be coded with unique TLVs. 281 The Length field (N) is defined as an unsigned integer that is two 282 bytes in length. This field can encode values from 0 to 65535. The 283 length field describes the number of bytes in the Value. Length does 284 not count the bytes used for the Type or Length. Note that the 285 length field of a TLVs using the CAtypes registry (such as those 286 defined in [RFC5139] are one byte. Since the type codes defined here 287 are restricted to be different from the CAtypes, the difference in 288 the length field can be accommodated. 290 The value field is defined explicitly for each shape in this 291 document. 293 5. Relative Location 295 Relative location is a shape (point, circle, ellipse...). The shape 296 is defined with a CRS that has a datum defined as the reference 297 (which appears as a civic address or geodetic location in the tuple), 298 and the shape coordinates as meter offsets North/East of the datum 299 measured in meters (with an optional Z offset relative to datum 300 altitude). An optional angle allows the reference CRS be to rotated 301 with respect to North. 303 The CRS for 2-D is denoted with an SRSname of 304 urn:ietf:params:geopriv:relative:2d, while the 3-D CRS is 305 urn:ietf:params:geopriv:relative:3d. A 2D offset MUST NOT be used 306 with a 3D reference, and a 3D offset MUST NOT be used with a 2D 307 reference 309 The baseline of the reference location is represented as like a normal PIDF-LO. Relative location adds a new element to Within 312 and elements are described. Within are 313 shape elements described below. 315 The individual elements of the relative location have unique TLV 316 assignments. A relative location encoded in TLV would have the 317 baseline location reference TLDs followed by an outer reference TLD 318 which contains within it the reference refinement TLVs. The 319 reference TLD is followed by the relative offset, and optional map 320 TLDs described in this document. 322 More than one relative shape MUST NOT be included in either a PIDF-LO 323 or TLV encoding of location for a given reference point. Any error 324 in the reference point transfers to the location described by the 325 relative location. Any errors arising from an implementation not 326 supporting or understanding elements of the reference point directly 327 increases the error (or uncertainty) in the resulting location. 329 5.1. Reference TLV 331 When a reference is encoded in TLV, the refinement of the baseline 332 location is represented in a reference TLV, inside of which are civic 333 CAtype TLVs (if the baseline was a civic) or geo TLVs (if the 334 baseline was a geo). 336 +------+------+------+------+------+------+------+ 337 | 111 | Length | Reference TLVs | 338 +------+------+------+------+------+------+------+ 340 Reference TLV 342 5.2. Orientation of Relative Offset Coordinate Reference System 344 The relative location element may contain an optional angle relative 345 to North that defines the CRS of the offset. The offset CRS scale is 346 always meters, and the datum is the reference. The angle is encoded 347 as a single precision floating point degrees, with 0.0 representing 348 North. In xml, the angle is contained in an element, 349 example 50.0. In TLV encoding: 351 +------+------+------+------+------+------+------+ 352 | 112 | Length | Angle | 353 +------+------+------+------+------+------+------+ 354 Relative Offset Orientation TLV 356 6. Shape Encoding 358 Shape data is used to represent regions of uncertainty in the 359 relative CRS. 361 The description of each shape type includes a description of how that 362 type is encoded in Geography Markup Language (GML) [OGC.GML-3.1.1], 363 consistent with the rules in [RFC5491], but with a relative CRS. The 364 CRS is identified by a distinguished urn --tbd-- defined by this 365 document. 367 6.1. Units of Measure 369 All distance measures used in shapes are expressed in meters using 370 single precision floating point values. 372 All orientation angles used in shapes are expressed in degrees using 373 single precision floating point values. Orientation angles are 374 measured from WGS84 Northing to Easting with zero at Northing. 375 Orientation angles in the relative coordinate system start from the 376 second coordinate axis (y or Northing) and increase toward the first 377 axis (x or Easting). 379 6.2. Coordinates 381 Coordinates are a sequence of numeric values. These are encoded as a 382 sequence of double precision floating point numbers. 384 Coordinates are represented using a single precision floating point 385 value as described in IEEE 754 [IEEE.754]. 387 Every CRS MUST define how many values are present in each set of 388 coordinates, the axes that each value applies to, the order of axes, 389 and the units that are used for each axis. 391 For the two-dimensional CRS, coordinates are made of two values. The 392 first value corresponds to latitude (Easting). The second value 393 corresponds to longitude (Northing). Both axis are rotated relative 394 to North by the ro-angle, if present. 396 For the three-dimensional CRS, coordinates are made of three values, 397 the first two of which are the same as for the two-dimensional CRS. 398 The third value corresponds to the altitude above the plane of the 399 horizontal at the reference location and is measured in meters. 401 6.3. On Uncertainty and Encoding 403 Binary-encoded coordinate values are considered to be a single value 404 without uncertainty. When encoding a value that cannot be exactly 405 represented, the best approximation is chosen according to 406 [Clinger1990]. 408 7. Shapes 410 Nine shape type codes are defined. 412 7.1. Point 414 A point "shape" describes a single point with unknown uncertainty. 415 It consists of a single set of coordinates. 417 In a two-dimensional CRS, the coordinate includes two values; in a 418 three-dimensional CRS, the coordinate includes three values. 420 7.1.1. XML encoding 422 A point is represented in GML using the following template: 424 426 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 427 429 GML Point Template 431 Where "$CRS-URN$" is replaced by a 432 urn:ietf:params:geopriv:relative:2d or 433 urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted 434 if the CRS is two-dimensional. 436 7.1.2. TLV encoding 438 The point shape is introduced by a TLV of 113 for a 2D point and 114 439 for a 3D point. 441 +------+-------------+ 442 | 113/4| Length | 443 +------+------+------+------+ 444 | Coordinate-1 | 445 +------+------+------+------+ 446 | Coordinate-2 | 447 +------+------+------+------+ 448 | (3D-only) Coordinate-3 | 449 +------+------+------+------+ 451 Point Encoding 453 7.2. Circle or Sphere Shape 455 A circle or sphere describes a single point with a single uncertainty 456 value in meters. 458 In a two-dimensional CRS, the coordinate includes two values and the 459 resulting shape forms a circle. In a three-dimensional CRS, the 460 coordinate includes three values and the resulting shape forms a 461 sphere. The uncertainty radius is specified as a single precision 462 floating point value (32 bits: 1 sign bit, 8 exponent bits, 23 463 fractional bits in binary). 465 The circle size is defined as a radius in meters encoded as single 466 precision floating point value 468 7.2.1. XML encoding 470 A circle is represented in and converted from GML using the following 471 template: 473 476 $Coordinate-1 $Coordinate-2$ 477 478 $Radius$ 479 480 482 GML Circle Template 484 A sphere is represented in and converted from GML using the following 485 template: 487 490 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 491 492 $Radius$ 493 494 496 GML Sphere Template 498 7.2.2. TLV encoding 500 A circular shape is introduced by a type code of 115. A spherical 501 shape is introduced by a type code of 116. 503 +------+-------------+ 504 | 115/6| Length | 505 +------+------+------+------+ 506 | Coordinate-1 | 507 +------+------+------+------+ 508 | Coordinate-2 | 509 +------+------+------+------+ 510 | (3D-only) Coordinate-3 | 511 +------+------+------+------+ 512 | Radius | 513 +------+------+------+------+ 515 Circle or Sphere Encoding 517 7.3. Ellipse or Ellipsoid Shape 519 A ellipse or ellipsoid describes a point with an elliptical or 520 ellipsoidal uncertainty region. 522 In a two-dimensional CRS, the coordinate includes two values, plus a 523 semi-major axis, a semi-minor axis, a semi-major axis orientation 524 (clockwise from North). In a three-dimensional CRS, the coordinate 525 includes three values and in addition to the two-dimensional values, 526 an altitude uncertainty (semi-vertical) is added. 528 Distance and angular measures are defined in meters and degrees 529 respectively. Both are encoded as single precision floating point 530 values. 532 7.3.1. XML encoding 534 An ellipse is represented in and converted from GML using the 535 following template: 537 540 $Coordinate-1 $Coordinate-2$ 541 542 $Semi-Major$ 543 544 545 $Semi-Minor$ 546 547 548 $Orientation$ 549 550 552 GML Ellipse Template 554 An ellipsoid is represented in and converted from GML using the 555 following template: 557 560 $Coordinate-1 $Coordinate-2$ $Coordinate-3$ 561 562 $Semi-Major$ 563 564 565 $Semi-Minor$ 566 567 568 $Semi-Vertical$ 569 570 571 $Orientation$ 572 573 575 GML Ellipsoid Template 577 7.3.2. TLV encoding 579 An ellipse is introduced by a type code of 117 and an ellipsoid is 580 introduced by a type code of 118. 582 +------+-------------+ 583 | 117/8| Length | 584 +------+------+------+------+ 585 | Coordinate-1 | 586 +------+------+------+------+ 587 | Coordinate-2 | 588 +------+------+------+------+ 589 | (3D-only) Coordinate-3 | 590 +------+------+------+------+------+------+------+------+ 591 | Semi-Major Axis | Semi-Minor Axis | 592 +------+------+------+------+------+------+------+------+ 593 | Orientation | (3D) Semi-Vertical Axis | 594 +------+------+------+------+------+------+------+------+ 596 Ellipse or Ellipsoid Encoding 598 7.4. Polygon or Prism Shape 600 A polygon or prism include a number of points that describe the outer 601 boundary of an uncertainty region. A prism also includes an altitude 602 and prism height. 604 At least 3 points MUST be included in a polygon. In order to 605 interoperate with existing systems, an encoding SHOULD include 15 or 606 fewer points, unless the recipient is known to support larger 607 numbers. 609 The height of the prism is encoded as a single precision floating 610 point value. 612 7.4.1. XML Encoding 614 A polygon is represented in and converted from GML using the 615 following template: 617 619 620 621 622 $Coordinate1-1$ $Coordinate1-2$ 623 $Coordinate2-1$ $Coordinate2-2$ 624 $Coordinate3-1$ ... 625 ... 626 $CoordinateN-1$ $CoordinateN-2$ 627 $Coordinate1-1$ $Coordinate1-2$ 628 629 630 631 633 GML Polygon Template 635 Alternatively, a series of "pos" elements can be used in place of the 636 single "posList". Each "pos" element contains two coordinate values. 638 Note that the first point is repeated at the end of the sequence of 639 coordinates and no explicit count of the number of points is 640 provided. 642 A GML polygon that includes altitude cannot be represented completely 643 in binary. When converting to the binary representation, a two 644 dimensional CRS is used and altitude is removed from each coordinate. 646 A prism is represented in and converted from GML using the following 647 template: 649 652 653 654 655 656 657 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 658 $Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$ 659 $Coordinate2-1$ ... ... 660 ... 661 $CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$ 662 $Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$ 663 664 665 666 667 668 669 $Height$ 670 671 673 GML Prism Template 675 Alternatively, a series of "pos" elements can be used in place of the 676 single "posList". Each "pos" element contains three coordinate 677 values. 679 7.4.2. TLV Encoding 681 A polygon is introduced with a type code of 119. A prism is 682 introduced with a type code of 120. 684 +------+-------------+ 685 |119/20| Length | 686 +------+------+------+------+------+------+ 687 | Count | (3D-only) Height | 688 +------+------+------+------+------+------+ 689 | Coordinate1-1 | 690 +------+------+------+------+ 691 | Coordinate1-2 | 692 +------+------+------+------+ 693 | (3D-only) Coordinate1-3 | 694 +------+------+------+------+ 695 | Coordinate2-1 | 696 +------+------+------+------+ 697 ... 698 +------+------+------+------+ 699 | CoordinateN-1 | 700 +------+------+------+------+ 701 | CoordinateN-2 | 702 +------+------+------+------+ 703 | (3D-only) CoordinateN-3 | 704 +------+------+------+------+ 706 Polygon or Prism Encoding 708 Note that unlike the polygon representation in GML, the first and 709 last points are not required to be the same in the TLV 710 representation. an explicit count of the number of points is provided 711 in 'Count'. 713 7.5. Arc-Band Shape 715 A arc-band describes a region constrained by a range of angles and 716 distances from a predetermined point. This shape can only be 717 provided for a two-dimensional CRS. 719 Distance and angular measures are defined in meters and degrees 720 respectively. Both are encoded as single precision floating point 721 values. 723 7.5.1. XML encoding 725 An arc-band is represented in and converted from GML using the 726 following template: 728 731 $Coordinate-1 $Coordinate-2$ 732 733 $Inner-Radius$ 734 735 736 $Inner-Radius$ 737 738 739 $Start-Angle$ 740 741 742 $Opening-Angle$ 743 744 746 GML Arc-Band Template 748 7.5.2. TLV Encoding 750 An arc-band is introduced by a type code of 122. 752 +------+-------------+ 753 | 121 | Length | 754 +------+------+------+------+ 755 | Coordinate | 756 +------+------+------+------+ 757 | Coordinate | 758 +------+------+------+------+------+------+------+------+ 759 | Inner Radius | Outer Radius | 760 +------+------+------+------+------+------+------+------+ 761 | Start Angle | Opening Angle | 762 +------+------+------+------+------+------+------+------+ 764 Arc-Band Encoding 766 8. Secondary Map Metadata 768 The optional "map" URL can be used to provide a user of relative 769 location with a visual reference for the location information. This 770 document does not describe how the recipient uses the map nor how it 771 locates the reference or offset within the map. Maps can be simple 772 images, vector files, 2-D or 3-D geospatial databases, or any other 773 form of representation understood by both the sender and recipient. 775 8.1. Map URL 777 In XML, the map is a element defined within 778 and contains the URL. The URL is encoded as a UTF-8 encoded string. 779 An "http:" or "https:" URL MUST be used unless the entity creating 780 the PIDF-LO is able to ensure that authorized recipients of this data 781 are able to use other URI schemes. A "map-type" attribute MUST be 782 present and specifies the kind of map the URL points to. Map types 783 are specified as mime media types as recorded in the IANA Media Types 784 registry. For example https:// 785 www.example.com/floorplans/123South/floor-2. In binary, the 786 maptype is a separate TLV from the map URL: 788 +------+------+------+------+------+------+-- --+------+ 789 | 122 | Length | maptype ... 790 +------+------+------+------+------+------+-- --+------+ 791 | 123 | Length | Map Image URL ... 792 +------+------+------+------+------+------+-- --+------+ 794 Map URL TLVs 796 8.2. Map Coordinate Reference System 798 The CRS used by the map depends on the type of map. For example, a 799 map described by a 3-D geometric model of the building may contain a 800 complete CRS description in it. For some kinds of maps, typically 801 described as images, the CRS used within the map must define the 802 following: 804 o The CRS origin 806 o The CRS axes used and their orientation 808 o The unit of measure used 810 This document provides elements that allow for a mapping between the 811 local coordinate reference system used for the relative location and 812 the coordinate reference system used for the map where they are not 813 the same. 815 8.2.1. Map Reference Point Offset 817 This optional element identifies the coordinates of the reference 818 point as it appears in the map. This value is measured in a map-type 819 dependent manner, using the coordinate system of the map. 821 For image maps, coordinates start from the upper left corner and 822 coordinates are first counted by column with positive values to the 823 right; then rows are counted with positive values toward the bottom 824 of the image. For such an image, the first item is columns, the 825 second rows and any third value applies to any third dimension used 826 in the image coordinate space. 828 The element contains 2 (or 3) coordinates similar to a 829 GML "pos", For example: 831 2670.0 1124.0 1022.0 833 Map Reference Point Example XML 835 +------+-------------+ 836 | 124 | Length | 837 +------+------+------+------+ 838 | Coordinate-1 | 839 +------+------+------+------+ 840 | Coordinate-2 | 841 +------+------+------+------+ 842 | (3D-only) Coordinate-3 | 843 +------+------+------+------+ 845 Map Reference Point Coordinates TLV 847 The encoding for coordinates is described in Section 6.2. 849 If omitted, a value containing all zeros is assumed. If the 850 coordinates provided contain fewer values than are needed, the first 851 value from the set is applied in place of any missing values. 853 8.2.2. Map Orientation 855 The map orientation includes the orientation of the map direction 856 ('UP') in relation to the Earth. Map orientation is expressed 857 relative to the orientation of the relative coordinate system. This 858 means that map orientation with respect to WGS84 North is the sum of 859 the two orientation fields. Both values default to zero if no value 860 is specified. 862 This type uses a single precision floating point value of degrees 863 relative to North. 865 In XML, the element contains a single floating point 866 value, example 67.00. In TLV form: 868 +------+------+------+------+------+------+------+ 869 | 125 | Length | Angle | 870 +------+------+------+------+------+------+------+ 872 Map Orientation TLV 874 8.2.3. Map Scale 876 The optional map scale describes the relationship between the units 877 of measure used in the map, relative to the meters unit used in the 878 relative coordinate system. 880 This type uses a sequence of IEEE 754 [IEEE.754] single precision 881 floating point values to represent scale as a sequence of numeric 882 values. The units of these values is map-type dependent, and could 883 for example be pixels per meter in image map-types. 885 A scaling factor is provided for each axis in the coordinate system. 886 For a two-dimensional coordinate system, two values are included to 887 allow for different scaling along the x and y axes independently. 888 For a three-dimensional coordinate system, three values are specified 889 for the x, y and z axes. 891 Alternatively, a single scaling value MAY be used to apply the same 892 scaling factor to all coordinate components. 894 Images that use a rows/columns coordinate system often use a left- 895 handed coordinate system. A negative value for the y/rows-axis 896 scaling value can be used to account for any change in direction 897 between the y-axis used in the relative coordinate system and the 898 rows axis of the image coordinate system. 900 In XML, the element may contain the single scale value, or 901 may contain 2 (or 3) values similar to a GML "pos" with separate 902 scale values. In TLV form: 904 +------+------+------+------+------+------+ 905 | 126 | Length | Scales ... 906 +------+------+------+------+------+------+ 908 Map Scale TLV 910 8.3. Map Example 912 An example of expressing a map is: 914 915 916 http://example.com/map.jpg 917 918 200 210 919 68 920 2.90 -2.90 921 923 Map Example 925 9. Examples 927 9.1. Civic PIDF with Polygon Offset 929 937 938 939 940 941 AU 942 NSW 943 Wollongong 944 North Wollongong 945 Flinders 946 Street 947 123 948 949 950 951 952 A 953 I 954 113 955 Front 956 957 958 959 961 962 963 433.0 -734.0 964 431.0 -733.0 965 431.0 -732.0 966 433.0 -731.0 967 434.0 -732.0 968 434.0 -733.0 969 433.0 -734.0 970 971 972 973 974 975 976 977 GPS 978 979 mac:1234567890ab 980 2007-06-22T20:57:29Z 981 982 984 9.2. Geo PIDF with Circle Offset 986 987 993 994 995 996 997 -34.407 150.883 998 999 50.0 1000 1001 1002 1003 1004 1005 -34.407 150.883 1007 1008 1009 1010 1012 500.0 750.0 1013 1014 5.0 1015 1016 1017 1018 1019 1020 https://www.example.com/flrpln/123South/flr-2 1021 2670.0 1124.0 1022.0 1022 67.00 1023 10 1024 1025 1026 1027 Wiremap 1028 1029 mac:1234567890ab 1030 2007-06-22T20:57:29Z 1031 1032 1033 1034 2003-06-22T20:57:29Z 1035 1036 1038 9.3. Civic TLV with Point Offset 1040 +--------+-------------------------------------------------+ 1041 | Type | Value | 1042 +--------+-------------------------------------------------+ 1043 | 0 | en | 1044 | | | 1045 | 1 | IL | 1046 | | | 1047 | 3 | Chicago | 1048 | | | 1049 | 34 | Wacker | 1050 | | | 1051 | 18 | Drive | 1052 | | | 1053 | 19 | 3400 | 1054 | | | 1055 | 112 | Reference | 1056 | | | 1057 | 40 | BBuilding|A | 1058 | | | 1059 | 40 | AFloor|6th | 1060 | | | 1061 | 40 | BSuite|213 | 1062 | | | 1063 | 40 | ADoor|Front | 1064 | | | 1065 | 115 | 100 70 | 1066 | | | 1067 | 122 | image/png | 1068 | | | 1069 | 123 | http://maps.example.com/3400Wacker/A6 | 1070 | | | 1071 | 124 | 0.0 4120.0 | 1072 | | | 1073 | 125 | 113.0 | 1074 | | | 1075 | 126 | 10.6 | 1076 +--------+-------------------------------------------------+ 1078 10. Schema Definition 1080 1081 1089 1093 1094 1096 Relative Location for PIDF-LO 1097 1098 1099 This schema defines a location representation that allows for 1100 the description of locations that are relative to another. 1101 An optional map reference is also defined. 1102 1103 1105 1107 1109 1110 1111 1112 1113 1114 1115 1117 1118 1119 1120 1121 1123 1124 1125 1126 1127 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1140 1141 1142 1143 1145 1146 1147 1148 1149 1150 1151 1153 1155 1157 1158 1159 1160 1162 1163 1164 1165 1167 1168 1169 1171 1173 1174 1175 1179 1180 1181 1182 1183 1185 1187 xml schema relative-location 1189 11. Security Considerations 1191 This document describes a data format. To a large extent, security 1192 properties of this depend on how this data is used. 1194 Privacy for location data is typically important. Adding relative 1195 location may increase the precision of the location, but does not 1196 otherwise alter its privacy considerations, which are discussed in 1197 [RFC4119] 1199 [[Not that interesting, but it could be relevant ?]] The fractional 1200 bits in IEEE 754 [IEEE.754] floating point values can be used as a 1201 covert channel. For values of either zero or infinity, non-zero 1202 fraction bits could be used to convey information. If the presence 1203 of covert channels is not desired then the fractional bits MUST be 1204 set to zero. There is no need to represent NaN (not a number) in 1205 this encoding. 1207 12. IANA Considerations 1209 12.1. Relative Location Registry 1211 This document creates a new registry called 'RLtypes'. As defined in 1212 [RFC5226], this registry operates under "IETF Consensus" rules. 1214 The content of this registry includes: 1216 RLtype: Numeric identifier, assigned by IANA. 1218 Brief description: Short description identifying the meaning of the 1219 element. 1221 Reference to published specification: A stable reference to an RFC 1222 which describes the value in sufficient detail so that 1223 interoperability between independent implementations is possible. 1225 IANA is requested to not permit values to be assigned into this 1226 registry which conflict with values assigned in the CAtypes registry 1227 or to permit values to be assigned into the CAtypes registry which 1228 conflict with values assigned to to this registry unless the IANA 1229 considerations section for the new value explicitly overrides this 1230 prohibition, and the document defining the value describes how 1231 conflicting TLV codes will be interpreted by implementations 1233 The values defined are: 1235 +--------+----------------------------------------+-----------+ 1236 | RLtype | description | Reference | 1237 +--------+-------+--------------------------------+-----------+ 1238 | 111 | relative location reference | this RFC | 1239 | 112 | relative location angle | this RFC | 1240 | 113 | relative location shape 2D point | this RFC | 1241 | 114 | relative location shape 3D point | this RFC | 1242 | 115 | relative location shape circlular | this RFC | 1243 | 116 | relative location shape spherical | this RFC | 1244 | 117 | relative location shape elliptical | this RFC | 1245 | 118 | relative location shape ellipsoid | this RFC | 1246 | 119 | relative location shape arc-band | this RFC | 1247 | 120 | relative location shape polygon | this RFC | 1248 | 121 | relative location shape prism | this RFC | 1249 | 122 | relative location map type | this RFC | 1250 | 123 | relative location map URI | this RFC | 1251 | 124 | relative location map coordinates | this RFC | 1252 | 125 | relative location map angle | this RFC | 1253 | 126 | relative location map scale | this RFC | 1254 +--------+-------+--------------------------------+-----------+ 1256 12.2. URN Sub-Namespace Registration 1258 This document registers a new XML namespace, as per the guidelines in 1259 [RFC3688]) that has been registered with IANA. 1261 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative 1263 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1264 Martin Thomson (martin.thomson@andrew.com). 1266 XML: 1268 BEGIN 1269 1270 1272 1273 1274 GEOPRIV Relative Location 1275 1276 1277

Format for representing relative location in GEOPRIV

1278

urn:ietf:params:xml:ns:pidf:geopriv10:relative

1279

See 1280 RFCXXXX.

1281 1282 1283 1286 END 1288 12.3. XML Schema Registration 1290 This section registers an XML schema as per the procedures in 1291 [RFC3688]. 1293 URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation 1295 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1296 Martin Thomson (martin.thomson@andrew.com). 1298 The XML for this schema can be found as the entirety of Section 7 1299 of this document. 1301 12.4. CRS public identifier registration 1303 This section registers two public identifiers as per the procedures 1304 in [RFC3688]. 1306 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d 1307 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1308 Martin Thomson (martin.thomson@andrew.com). 1310 XML: 1312 BEGIN 1313 1314 1316 1317 1318 GEOPRIV Relative Location 2d CRS 1319 1320 1321

Identifier for a 2D CRS in GEOPRIV relative location

1322

urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d

1323

See 1324 RFCXXXX.

1325 1326 1327 1330 END 1332 URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d 1334 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 1335 Martin Thomson (martin.thomson@andrew.com). 1337 XML: 1339 BEGIN 1340 1341 1343 1344 1345 GEOPRIV Relative Location 3d CRS 1346 1347 1348

Identifier for a 3D CRS in GEOPRIV relative location

1349

urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d

1350

See 1351 RFCXXXX.

1352 1353 1354 1357 END 1359 13. Acknowledgements 1361 This is the product of a design team on relative location. Besides 1362 the authors, this team included: Marc Linsner, James Polk, and James 1363 Winterbottom. 1365 14. References 1367 14.1. Normative References 1369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1370 Requirement Levels", BCP 14, RFC 2119, March 1997. 1372 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location 1373 Object Format", RFC 4119, December 2005. 1375 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration 1376 Protocol (DHCPv4 and DHCPv6) Option for Civic 1377 Addresses Configuration Information", RFC 4776, 1378 November 2006. 1380 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic 1381 Location Format for Presence Information Data Format 1382 Location Object (PIDF-LO)", RFC 5139, February 2008. 1384 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 1385 Writing an IANA Considerations Section in RFCs", 1386 BCP 26, RFC 5226, May 2008. 1388 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, 1389 "GEOPRIV Presence Information Data Format Location 1390 Object (PIDF-LO) Usage Clarification, 1391 Considerations, and Recommendations", RFC 5491, 1392 March 2009. 1394 [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. 1395 Whiteside, "Geographic information - Geography 1396 Markup Language (GML)", OpenGIS 03-105r1, 1397 April 2004, . 1400 [OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 1401 Application Schema for use by the Internet 1402 Engineering Task Force (IETF)", OGC Best 1403 Practice 06-142r1, Version: 1.0, April 2007. 1405 [IEEE.754] IEEE, "IEEE Standard for Binary Floating-Point 1406 Arithmetic", IEEE Standard 754-1985, January 2003. 1408 [Clinger1990] Clinger, W., "How to Read Floating Point Numbers 1409 Accurately", Proceedings of Conference on 1410 Programming Language Design and Implementation pp. 1411 92-101, 1990, 1412 . 1415 14.2. Informative References 1417 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, 1418 RFC 3688, January 2004. 1420 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 1421 "Uniform Resource Identifier (URI): Generic Syntax", 1422 STD 66, RFC 3986, January 2005. 1424 Authors' Addresses 1426 Martin Thomson 1427 Andrew Corporation 1428 Andrew Building (39) 1429 Wollongong University Campus 1430 Northfields Avenue 1431 Wollongong, NSW 2522 1432 AU 1434 EMail: martin.thomson@andrew.com 1436 Brian Rosen 1437 Neustar 1438 470 Conrad Dr 1439 Mars, PA 16046 1440 US 1442 EMail: br@brianrosen.net 1443 Dorothy Stanley 1444 Aruba Networks 1445 1322 Crossman Ave 1446 Sunnyvale, CA 94089 1447 US 1449 EMail: dstanley@arubanetworks.com 1451 Gabor Bajko 1452 Nokia 1453 323 Fairchild Drive 1454 Mountain View, CA 94043 1455 US 1457 EMail: gabor.bajko@nokia.com 1459 Allan Thomson 1460 Cisco Systems, Inc. 1461 170 West Tasman Drive 1462 San Jose, CA 95134 1463 US 1465 EMail: althomso@cisco.com