idnits 2.17.1 draft-thomson-geopriv-indoor-location-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (November 30, 2009) is 5253 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) -- Looks like a reference, but probably isn't: '5' on line 521 -- Looks like a reference, but probably isn't: '13' on line 521 -- Looks like a reference, but probably isn't: '0' on line 777 == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-01 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew Corporation 5 Expires: June 3, 2010 November 30, 2009 7 Locations with Locally-Defined Coordinate Reference Systems for the 8 Presence Information Data Format - Location Object (PIDF-LO) 9 draft-thomson-geopriv-indoor-location-01 11 Abstract 13 A method is described for constructing a Presence Information Data 14 Format - Location Object (PIDF-LO) document that contains location 15 information using a locally-defined coordinate reference system 16 (CRS). This form of representation allows for use of locally-defined 17 coordinates with potential advantages for improved accuracy and 18 usability in local context, in particular location applications that 19 operate indoors. A framework for defining a local CRS is provided. 20 A process for transformation of coordinates defined in the local CRS 21 and the widely used World Geodetic System 1984 (WGS84) CRS is 22 defined. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on June 3, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Example Use Case . . . . . . . . . . . . . . . . . . . . . 5 66 2. Conventions used in this document . . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Generating Local Location Information . . . . . . . . . . . . 7 69 4.1. Local Map Image . . . . . . . . . . . . . . . . . . . . . 8 70 5. Local Coordinate Reference System . . . . . . . . . . . . . . 8 71 5.1. Cartesian Coordinate System . . . . . . . . . . . . . . . 9 72 5.2. Local or Indoor Datum . . . . . . . . . . . . . . . . . . 9 73 5.2.1. Anchor Location . . . . . . . . . . . . . . . . . . . 10 74 5.2.2. Orientation . . . . . . . . . . . . . . . . . . . . . 10 75 6. Local Map Presentation . . . . . . . . . . . . . . . . . . . . 11 76 6.1. Image Coordinates . . . . . . . . . . . . . . . . . . . . 11 77 6.2. Map Image . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.3. Reference Location . . . . . . . . . . . . . . . . . . . . 13 79 6.4. Pixel Offset . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.5. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.5.1. Map Projections . . . . . . . . . . . . . . . . . . . 14 82 7. Coordinate Transformation . . . . . . . . . . . . . . . . . . 15 83 7.1. Conversion from WGS84 to Local CRS . . . . . . . . . . . . 15 84 7.2. Conversion from Local CRS to WGS . . . . . . . . . . . . . 17 85 7.3. Transformation Matrix . . . . . . . . . . . . . . . . . . 18 86 7.4. Managing Uncertainty . . . . . . . . . . . . . . . . . . . 18 87 7.5. Angles of Orientation . . . . . . . . . . . . . . . . . . 19 88 8. Example PIDF-LO . . . . . . . . . . . . . . . . . . . . . . . 19 89 9. GML Definitions . . . . . . . . . . . . . . . . . . . . . . . 21 90 9.1. Units of Measure . . . . . . . . . . . . . . . . . . . . . 21 91 9.2. Code Space Definitions . . . . . . . . . . . . . . . . . . 22 92 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 12.1. URN Sub-Namespace Registration for 96 'urn:ietf:params:xml:ns:geopriv:indoor' . . . . . . . . . 27 97 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 101 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 102 Appendix A. Calculating WGS84 ECEF Up, North and East Vectors . . 30 104 1. Introduction 106 Providing location information in indoor environments presents new 107 sets of technical challenges and use cases for location determination 108 and representation. For use indoors, location information that is in 109 a form specific to that locality can be both more accurate and more 110 usable. 112 The ability to specify relative coordinates simplifies the use of 113 local applications, especially local mapping or navigation 114 applications, which often rely on floor plan images or provide 115 directions based on fixtures of the local environment. 117 Within the confines of a building, or in any local context, location 118 information might be determined in relation to fixtures in that 119 environment. This might provide location information that is highly 120 accurate within a local region, but errors are added if conversion to 121 a globally useful form like World Geodetic System 1984 (WGS84) are 122 required. 124 For instance, wireless positioning systems within a building might 125 provide excellent accuracy in relation to the wireless 126 transmitters. However, in converting locations in a local 127 reference frame to a globally applicable systems such as WGS84, 128 these systems encounter difficulties. 130 On the other hand, Global Navigation Satellite Systems (GNSS), 131 which are widely used to generate location information, operate 132 poorly indoors or anywhere an unobstructed view of the sky cannot 133 be found. 135 For these cases and others like them, avoiding conversion steps 136 ensures that unnecessary errors are not introduced. 138 1.1. Solution 140 A means to describe a location in relation to a fixed reference is 141 defined. These locations use the forms defined in [OGC.GeoShape], 142 using a custom coordinate reference system (CRS). 144 A form for defining a local CRS is described, such that locations in 145 that CRS can be trivially translated to and from the World Geodetic 146 System 1984 (WGS84) CRS used in PIDF-LO. This allows for location to 147 be expressed in a canonical form, while preserving the location 148 information for use in the local context. 150 Guidelines are further provided for constructing a Presence 151 Information Data Format - Location Object (PIDF-LO) document 153 [RFC4119] so that existing applications and consumers of location 154 information are able to operate. These guidelines are based on those 155 described in RFC 5491 [RFC5491]. 157 1.2. Example Use Case 159 A shopper uses the information contained in a PIDF-LO to identify the 160 location of a store in a mall. The geodetic location information 161 [OGC.GeoShape] or civic address information [RFC5139] helps the 162 shopper identify the location of the mall. 164 The relative, or indoor, location representation helps the shopper 165 find the store within the mall. This information can be used 166 together with a map of the mall, providing information in a form that 167 is more readily usable to the shopper. The location of the store or 168 the shopper can be overlaid on the provided map, aiding in finding 169 the store. 171 Transformation from WGS84 to the local CRS allows the shopper to use 172 location determination methods that are not aware of the local CRS. 173 Conversely, the location in the local CRS can be transformed into a 174 geodetic location for use outside of the mall, or for applications 175 that are unaware of the local context. 177 2. Conventions used in this document 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 3. Overview 185 A location in a user-defined CRS is included in a PIDF-LO document as 186 shown in Figure 1, which includes the high-level elements involved. 188 190 * geodetic tuple 191 192 * geodetic location 193 ... 194 196 * indoor tuple 197 199 * indoor location 201 * local CRS 202 #indoorCRS 203 * coordinate system 204 205 * local datum 206 207 209 * image information 210 ... 211 213 215 Figure 1: PIDF-LO Structure Overview 217 Two tuples are included in the PIDF-LO. One containing geodetic 218 location information, the second containing locally defined 219 coordinates. Depending on how the location generator operates, 220 transformation (Section 7) might be used to construct one or other 221 location element. 223 The first "tuple" (or "device" or "person") contains geodetic 224 information [OGC.GeoShape]. This first tuple uses a WGS84 CRS, so 225 that the information is usable outside of the local context. 227 Aside from being required by [RFC5491], this ensures that overly 228 simplistic processors that rely on tuple ordering do not 229 erroneously assume the use of WGS84 with the subsequent shape 230 information. 232 A second "tuple" includes location information using a Geography 233 Markup Language (GML) [OGC.GML-3.1.1] geometry element, but using a 234 custom, geo-referenced CRS in place of the WGS84 reference that is 235 used for the geodetic shape. A formal definition of the CRS is 236 included in the tuple with the shape. 238 The CRS is defined only within the scope of the PIDF-LO. A URI 239 fragment identifier is used to identify the CRS "srsName" parameters 240 that reference the CRS. 242 A reference to a GML dictionary containing the CRS MAY be used in 243 place of the fragment identifier used in this document. An "http:" 244 or "https:" URI MUST be used for this purpose unless an alternative 245 scheme is known to be supported or recognized by recipients of the 246 PIDF-LO. Authors of PIDF-LO documents that rely on providing a 247 reference to the CRS need to have some assurance that all potential 248 recipients of the location information are either able to resolve the 249 reference or do not require the local information. 251 This document describes a means of generating a geodetic location 252 from a locally defined location, providing that the reference point 253 of the local CRS is specified as a geodetic location. If a civic 254 address is used as a reference point, other information is needed to 255 ensure that the location information is useful outside of the local 256 context. 258 4. Generating Local Location Information 260 When creating location information for use in a local context, a 261 coordinate reference system definition is required. Once the CRS is 262 defined, the shapes from [OGC.GeoShape] can be used with an "srsName" 263 attribute that references the newly defined CRS, rather than WGS84. 265 The locally-defined shapes only differ from those in [OGC.GeoShape] 266 by the CRS identifier used: 268 269 47.5 22 270 2.4 271 272 274 A GML "EngineeringCRS" element is used to define a local coordinate 275 reference system. An engineering CRS is formed of an identifier and 276 name, a coordinate system and a datum. 278 The "gml:id" attribute of "EngineeringCRS" contains any valid XML 279 name. The "srsName" includes a URI fragment [RFC3986] that refers to 280 this identifier; this value is used in the "srsName" in place of a 281 WGS84 CRS URI. No "codeSpace" attribute is included. 283 284 #indoorCRS 286 The CRS then needs a reference to the coordinate system defined in 287 this document (Section 5.1). This reference is provided using an 288 XLink [W3C.REC-xlink-20010627] attribute: 290 293 An engineering datum is used to define how the coordinate system then 294 relates to the local environment. This uses the "IndoorDatum" 295 element defined in this document (Section 5.2). This uses similar 296 identification to the CRS definition: 298 300 #officeDatum 301 ... 302 304 An indoor datum requires a reference point (Section 5.2.1) and an 305 orientation (Section 5.2.2) angle. The reference point is described 306 using either a geodetic shape [OGC.GeoShape], a civic address 307 [RFC5139], or both elements according to the rules in RFC 5491 308 [RFC5491]. A complete example document is included in Section 8. 310 4.1. Local Map Image 312 An optional map image can be provided to be used in presenting the 313 local information. If a map image is used as a reference, then pixel 314 coordinates from an image can then be used directly. 316 317 318 319 320 321 323 The manner in which a map image can be related to the local 324 coordinate system is described in Section 6. 326 5. Local Coordinate Reference System 328 A coordinate reference system (CRS) requires the definition of a 329 coordinate system, and a description of how that coordinate system 330 relates to a particular model of physical space. 332 The coordinate system used in relation to images is defined in this 333 document. All images use the same coordinate system. Two coordinate 334 systems are defined, identified by the URNs: 336 o urn:ietf:params:xml:schema:geopriv:indoor#cs3d 338 o urn:ietf:params:xml:schema:geopriv:indoor#cs2d 340 The datum that establishes the origin for the coordinate system is 341 defined during construction of the PIDF-LO. The datum is anchored to 342 a specific location. 344 Section 8 shows an example definition of an coordinate reference 345 system that include the definition of a location-specific datum that 346 corresponds to a specific anchor point. 348 5.1. Cartesian Coordinate System 350 A custom coordinate reference system (CRS) is defined for use in 351 representing indoor locations. This allows positions to be expressed 352 in relation to a floor plan or map. 354 Section 10 includes the definition of two Cartesian coordinate 355 systems. The two-dimensional Cartesian coordinate system is 356 identified by the URN 357 "urn:ietf:params:xml:schema:geopriv:indoor#cs2d". The three- 358 dimensional Cartesian coordinate system is identified by the URN 359 "urn:ietf:params:xml:schema:geopriv:indoor#cs3d". 361 The coordinate system described is positively oriented (that is, it 362 is right-handed). The two-dimensional coordinate system uses x- and 363 y-axes to represent coordinates. The three-dimensional coordinate 364 system adds a z-axis. 366 5.2. Local or Indoor Datum 368 The image datum establishes a relationship between the coordinate 369 system and a physical space. 371 An extension of the GML "ImageDatum" type is used to define a datum 372 precisely. This definition allows for transformation between the 373 local CRS and WGS84. 375 Note: WGS84 coordinates are specified in the order of latitude, 376 longitude, altitude. The local coordinate system is specified in 377 order: x, y, z. With an orientation of zero the x-axis roughly 378 corresponds to longitude, and the y-axis to the inverse of 379 latitude. Following the process described in Section 7 ensures 380 that this "reordering" does not introduce errors. 382 5.2.1. Anchor Location 384 This engineering datum identifies a point in space as the location of 385 the origin. This can be objectively specified using WGS84 386 coordinates in a geodetic shape [OGC.GeoShape]; alternatively, it can 387 be subjectively specified using a civic address [RFC5139]. Both 388 forms of location data MAY be included. 390 The form of reference location that is used depends on what purpose 391 the information is intended to serve. A geodetic reference location 392 provides a basis for unambiguous transformation between locations in 393 the locally-defined CRS and WGS84. Civic addresses are often more 394 readily usable by people. 396 The "anchor" element allows for the inclusion of any form of GML 397 geometry. Geodetic shapes produced by implementations conforming to 398 this specification MUST use one of the forms described in 399 [OGC.GeoShape]. 401 A single reference point can derived from the provided location. The 402 centroid of the geodetic shape [I-D.thomson-geopriv-uncertainty] is 403 used if the origin is included with uncertainty. This point is used 404 to anchor the local datum, as well as establishing the plane of the 405 horizontal. 407 The means for determining a point from a civic address is not 408 defined. The "LOC" field of the civic address can be used to provide 409 a textual description of the reference point. 411 5.2.2. Orientation 413 In many cases, it is convenient to use a rotated coordinate system in 414 the local context. It is rare that a building is neatly aligned with 415 North. Within the local context, directions are made in relation to 416 the building, not the cardinal directions. 418 Maps for use within structures are only rarely produced with geodetic 419 North toward the top of the image. Building maps are often oriented 420 so that the majority of features do not appear at irregular angles on 421 the map. 423 The "orientation" element provides a way to use locally useful 424 coordinates. This element contains a single angular measure that 425 describes how the local coordinate system is oriented in relation to 426 the North and East directions from the reference point (see 427 Appendix A). 429 The positive x-axis corresponds to an Easting vector at the anchor 430 point, rotated in a clockwise direction (that is, Northing to 431 Easting) about the vertical by the orientation angle. Similarly, the 432 y-axis corresponds to a rotated Northing vector. 434 ^ North 435 | 436 | _ 437 +--._ /\ y-axis 438 | `. / (north+o) 439 | / 440 | / 441 | / 442 | / 443 | / 444 | / 445 |/ East 446 o-------------+---------> 447 `-._ | 448 `-._ ; orientation 449 `-._/ 450 `-._ 451 `_| x-axis 452 [ Up == z-axis ] (east+o) 454 The z-axis in the three-dimensional coordinate system is oriented 455 directly upwards from the plane tangential to the WGS84 ellipsoid at 456 the anchor point. This is unaffected by the orientation angle. 458 6. Local Map Presentation 460 A map image can be referred to using the "localMap" element. This 461 allows for the locally defined location to be presented with 462 additional context. 464 Image information is placed in the "location-info" element after the 465 shape information and CRS. 467 6.1. Image Coordinates 469 A position on an image generally uses a coordinate system with an 470 origin in the upper left. For a two-dimensional image, a columns- 471 axis increases to the right and a rows-axis increases towards the 472 bottom of the image. 474 This left-handed coordinate system - inherited from the path that the 475 beam in a Cathode-ray tube follows - does not directly map to the 476 axes used in the local, Cartesian coordinate system. The rows-axis 477 is in the opposite direction to the y-axis. 479 (local coordinates) 480 ^ 481 | 482 y-axis 483 | 484 | 485 ---- x-axis ----> 486 O------------------------------+ 487 | ---- columns-axis ----> | 488 | | | 489 | | | 490 | rows-axis | 491 | | | 492 | v | 493 | (image coordinates) | 494 +------------------------------+ 496 Figure 2: Image Axes 498 If a left-handed coordinate system is used in an image, the scale 499 (Section 6.5) element can be used to convert negative y-axis values 500 into positive rows-axis values. A negative value for the rows/y 501 value (the second value) can be used for this purpose. 503 Some image types specifically defined how coordinates are interpreted 504 for the image. However, if this is not specified or unknown for the 505 image type and it is necessary to place a point with sub-pixel 506 precision, whole integer values in image coordinates are found at the 507 low-valued corner of the referenced pixel. This is usually the top 508 left corner of the pixel where row/column coordinates are used. 510 For instance, the pixel at [5,13] in the following covers the column 511 range 5.0 to 6.0 and the row range from 13 to 14. 513 4 5 6 7 514 | | | | 515 12 --+--------+--------+--------+- 516 | | | | 517 | | | | 518 | | | | 519 13 --+--------+--------+--------+- 520 | | | | 521 | | [5,13] | | 522 | | | | 523 14 --+--------+--------+--------+- 524 | | | | 525 | | | | 526 | | | | 527 15 --+--------+--------+--------+- 528 | | | | 530 Whole Integer Image Coordinates 532 6.2. Map Image 534 The optional "image" element includes an image, usually a map of the 535 locality. This image might be used to display the associated 536 location information to a user. 538 Rather than include an image inline, this uses XLink 539 [W3C.REC-xlink-20010627] to reference an image document. The 540 "xlink:href" attribute contains a URL for the image. An "http:" or 541 "https:" URI MUST be used unless the location generator is able to 542 ensure that authorized recipients of this data are able to use other 543 URI schemes. 545 6.3. Reference Location 547 The "referenceLocation" element describes the reference location used 548 to place (and orient) the image in space. This can be specified in 549 the same way that the anchor location (Section 5.2.1) for the datum 550 is specified using a geodetic shape or civic address. 552 If a local CRS is defined in the same document, the reference point 553 SHOULD refer the origin of the coordinate reference system, using the 554 "crsOrigin" element. This references the anchor point used in the 555 CRS definition, saving unnecessary duplication of this information. 557 The rows-axis of the image is either along the negative y-axis of a 558 Cartesian CRS or Southing from the reference point. The columns-axis 559 of the image is along the positive y-axis or Easting from the 560 reference point. Any vertical axis is oriented along the z-axis or 561 directly up from the reference point. See Appendix A for details on 562 how to determine North, East and Up vectors from an arbitrary point. 564 6.4. Pixel Offset 566 The anchor point is matched to a point on the image, thus 567 establishing a common point in both coordinate reference systems. 568 The "offset" element includes the coordinates of the reference point 569 in the image. 571 6.5. Scaling 573 The "scale" element includes a value in pixels per meter that 574 describes how coordinates in the local datum, specified in meters, 575 are translated to coordinates on the image at the reference point. 577 A scaling factor is provided for each axis in the coordinate system. 578 For a two-dimensional coordinate system, two values are included to 579 allow for different scaling along the x/columns- and y/rows-axes 580 independently. For a three-dimensional coordinate system, three 581 values are specified for the x/columns-, y/rows- and z/vertical-axes. 583 Alternatively, a single scaling value MAY be used to apply the same 584 scaling factor to all coordinate components (x/columns- and y/rows- 585 axes, and optionally the z/vertical-axis). 587 A negative value for the y/rows-axis scaling value can be used to 588 account for the change in direction between the y-axis and the rows 589 axis, as shown in Figure 2. 591 6.5.1. Map Projections 593 The method used to orient and scale a map image is limited in 594 applicability. This method does not account for distortion produced 595 by the curvature of the Earth. That is, it does not allow for the 596 additional complexity that would be necessary to accomodate different 597 map projection methods. The coordinate space used is strictly 598 Cartesian. 600 The Cartesian coordinate system suits maps with a orthographic 601 projection centered at the reference point. It also suits 602 architectural drawings and diagrams that also do not account for the 603 curvature of the Earth. 605 This does not necessarily prevent the use of alternative map 606 projections. For other map projections, the scaling factor changes 607 as the distance from the reference point increases. 609 Over small distances, an orthographic projection might be assumed. 610 Any errors introduced by this simplication might be acceptable for an 611 application. This simplication is only appropriate for maps that 612 cover small distances or where any errors resulting from use of 613 different map projections are acceptable. 615 7. Coordinate Transformation 617 It is often important that location information be provided that can 618 be used in a global context, as well as the local context. This 619 section describes how shapes can be transformed between the WGS84 CRS 620 and the local CRS. 622 A single point is selected in the image coordinate reference system. 623 This might be the origin of the image (0, 0), or any other point. 624 The corresponding point in WGS84 (latitude, longitude, altitude) is 625 also identified. 627 Selecting a point in each coordinate system establishes a reference 628 point: an origin point. When converting, all coordinates are 629 expressed relative to the corresponding point in the same coordinate 630 system. 632 7.1. Conversion from WGS84 to Local CRS 634 To convert coordinates specified in WGS84 to coordinates specified in 635 the local CRS use the following algorithm: 637 1. If the coordinates do not include altitude, add an altitude of 638 zero. This will be removed from the final result, but an 639 altitude value is required for this algorithm. 641 2. Convert the WGS84 (latitude, longitude, altitude) coordinates to 642 WGS84 ECEF (X, Y, Z) values. One commonly used algorithm for 643 this is documented in [I-D.thomson-geopriv-uncertainty]. 645 3. If necessary, find the centroid of the reference location, 646 specified in the "anchor" element, in WGS84 ECEF (X, Y, Z) 647 coordinates. Algorithms for this are documented in 648 [I-D.thomson-geopriv-uncertainty]. 650 4. Subtract the ECEF reference location from the ECEF coordinates to 651 get a relative position vector for the coordinates. 653 5. Multiply the resulting relative position by the forward 654 transformation matrix described in Section 7.3. This gives 655 distances in meters for each of the axes of the local coordinate 656 system. 658 6. If altitude was not originally provided, remove any vertical or 659 z-axis component. 661 7. If the reference location contains uncertainty, add this 662 uncertainty to any uncertainty in the original location, see 663 Section 7.4. 665 The results can be summarized as: 667 C[local] = R * T[0] * (C[ecef] - R[ecef]) 669 Where all coordinates are expressed as column vectors and "*" is the 670 matrix product. 672 The WGS84 reference point also establishes a reference plane for the 673 image. The reference plane is the plane of the horizontal at that 674 point - the plane tangential to the WGS84 ellipsoid at the reference 675 point. This plane, along with the orientation angle, are used to 676 create a transformation matrix. 678 Coordinates can then be plotted on the map image by applying the 679 following process: 681 1. Multiply each component of the vector by the scaling factor, 682 specified in the "scale" element, to obtain values in pixels. 684 2. Add the resulting value to the image offset, specified in the 685 "offset" element, to obtain the coordinates in the image. 687 If the image uses a different reference point to the origin of the 688 local CRS, then the coordinates must first be transformed into 689 coordinates in a local CRS that is centered about that reference 690 point. 692 The results can be summarized as: 694 C[image] = offset + scale .* C[local] 696 Where ".*" is the Hadamard or entrywise product. 698 7.2. Conversion from Local CRS to WGS 700 To convert coordinates specified in the local CRS to coordinates 701 specified in WGS84 use the following algorithm: 703 1. If the coordinates do not include a vertical or z-axis component, 704 set this value to zero. 706 2. Multiply the resulting relative position by the reverse 707 transformation matrix described in Section 7.3 to get a vector 708 relative to the reference location. 710 3. If necessary, find the centroid of the reference location, 711 "origin", in WGS84 ECEF (X, Y, Z) coordinates. 713 4. Add the ECEF reference location to the ECEF coordinates. 715 5. Convert the WGS84 ECEF (X, Y, Z) coordinates to WGS84 (latitude, 716 longitude, altitude) values. 718 6. If vertical or z-axis values were not provided, remove the 719 altitude value. 721 7. If the reference location contains uncertainty, add this 722 uncertainty to any uncertainty in the original location. 724 The results can be summarized as: 726 C[ecef] = transpose(R * T[0]) * (C[local]) + R[ecef] 728 Where "transpose(...)" signifies the matrix transpose. 730 If image coordinates are known, the local coordinates can be found by 731 first following these steps: 733 1. Subtract the image offset from the coordinate values. 735 2. Divide each component of the vector by the scaling factor. 737 The results can be summarized as: 739 C[local] = (1/scale) .* (C[image] - offset) 741 Where "1/scale" is 1 divided by the scaling factor. 743 7.3. Transformation Matrix 745 The transformation matrix used to convert coordinates between WGS84 746 and the local CRS uses the centroid of the origin location, contained 747 in the "origin" element. 749 The transformation matrix is formed from the North, East and Up 750 vectors from the origin location. Appendix A describes how to 751 determine these vectors in WGS84 ECEF coordinates: 753 East = [ -sinlng ; coslng ; 0 ] 754 North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ] 755 Up = [ coslat * coslng ; coslat * sinlng ; sinlat ] 757 This is used directly to form the following transformation matrix for 758 the case where the orientation is zero: 760 [ -sinlng ; coslng ; 0 ] 761 T[0] = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ] 762 [ coslat * coslng ; coslat * sinlng ; sinlat ] 764 The orientation of the map, included in the "orientation" element, 765 affects the x-axis and y-axis parts of this matrix. The rotation 766 matrix is a counter-clockwise rotation matrix, as follows: 768 [ cos(orientation) ; -sin(orientation) ; 0 ] 769 R = [ sin(orientation) ; cos(orientation) ; 0 ] 770 [ 0 ; 0 ; 1 ] 772 Both "R" and "T[0]" perform rotations. The final transformation 773 matrix is then the product of the rotation matrix and the coordinate 774 transformation matrix. This gives the following orthonormal 775 coordinate transformation matrix. 777 T = R * T[0] 779 When transforming from local coordinates to WGS84, the transformation 780 matrix is transposed to find its inverse. 782 7.4. Managing Uncertainty 784 The WGS84 origin location MAY include uncertainty if that location is 785 not sufficiently accurate. In this case, the centroid of the 786 uncertainty region is used as the origin point. The uncertainty in 787 this location increases any uncertainty when performing a 788 transformation. 790 An increase to uncertainty is applied when transforming both to and 791 from WGS84. Repeated transformations can increase uncertainty 792 indefinitely. 794 Converting the origin location and the target shape to a Circle or 795 Sphere prior to transformation simplifies the management of 796 uncertainty. The resulting uncertainty radius is the sum of the 797 radius from the original shape, plus the radius from the origin 798 location. 800 7.5. Angles of Orientation 802 Translation of Ellipse, Ellipsoid and ArcBand shapes requires that 803 the included angle measures are rotated. When translating from the 804 local coordinate reference system, the orientation of the image datum 805 is added to the angle. The orientation of the image datum is 806 subtracted when translating from WGS84 coordinates. 808 8. Example PIDF-LO 810 The following example PIDF-LO document contains geodetic location in 811 the first tuple, followed by a similar location in the local CRS. A 812 map image is also included. All other optional elements are omitted 813 from this example. 815 825 826 827 828 829 830 -34.407124 150.882673 831 10 832 833 834 835 836 837 838 839 840 841 842 843 844 47.5 22 845 2.4 846 847 849 850 #officeCRS 851 853 854 855 #officeDatum 856 857 858 -34.407168 150.882533 859 5 860 861 862 863 AU 864 NSW 865 Wollongong 866 Gwynneville 867 Northfields 868 Avenue 869 University of Wollongong 870 Director's Office 871 2 872 Andrew Corporation 873 2500 874 39 875 office 876 877 878 8.4 880 881 882 883 885 886 887 888 889 890 374 184 892 893 20 895 896 897 899 900 901 902 903 905 9. GML Definitions 907 Formal GML definitions for a coordinate reference system are provided 908 in the PIDF-LO. However, these definitions rely on the definitions 909 in this document, plus the formal GML definitions included in the 910 schema (Section 10). 912 This section provides references to definitions of the various code 913 points used in the formal definitions. 915 9.1. Units of Measure 917 This document uses the same restricted set of units of measure as 918 defined in [RFC5491], with additions for the local CRS. 920 The units for meters (urn:ogc:def:uom:EPSG::9001), degrees 921 (urn:ogc:def:uom:EPSG::9102) and radians (urn:ogc:def:uom:EPSG::9101) 922 are used where applicable. Meters are used for all distance 923 measures. Degrees or radians are used for all angular measures. 925 A pixel is defined as a subjective length measure. In this 926 definition, a pixel does cannot be used directly with other forms of 927 length measure. The pixel measure is context-dependent and can be 928 related to other length measures by different factors. The scaling 929 (Section 6.5) parameters establish how pixels relate to other 930 measures for a particular image. 932 Additional units of measure are defined for pixels 933 (urn:ietf:params:xml:schema:geopriv:indoor#px) and pixels per meter 934 (urn:ietf:params:xml:schema:geopriv:indoor#pxpm). Formal definitions 935 of these units are included in an annotation to the XML schema. 936 Pixel coordinates are used to describe a position in an image. 937 Pixels per meter are used to establish a scale for conversion between 938 meters and pixels. 940 9.2. Code Space Definitions 942 The GML definitions for the local coordinate system rely on 943 identifiers that are defined in the "http://ietf.org/rfc/rfcXXXX.txt" 944 (the URL of this document [[EDITOR NOTE: Please update this link at 945 publication]]). These identifiers are defined thus: 947 x The x-axis of the local coordinate system. 949 y The y-axis of the local coordinate system. 951 z The z-axis of the three-dimensional local coordinate system. 953 east+o East from the reference point, rotated clockwise (about the 954 Up vector) by the orientation angle, see Appendix A and 955 Section 7.3. 957 north+o North from the reference point, rotated clockwise (about the 958 Up vector) by the orientation angle, see Appendix A and 959 Section 7.3. 961 up Up from the reference point, see Appendix A and Section 7.3. 963 pixel The name for the pixels unit of measure, see Section 9.1. 965 px The abbreviated name for the pixels unit of measure. 967 pixels per metre The English name for the pixels per meter unit of 968 measure, using the standard spelling, see Section 9.1. 970 pxpm The abbreviated name for the pixels per meter unit of measure. 972 Documents created to represent local locations use a document-local 973 code space, signified by the absence of the "codeSpace" attribute. 975 10. XML Schema 977 The XML schema for the indoor location elements also includes a 978 definition of the 2-dimensional and 3-dimensional local coordinate 979 systems and units of measure used in definitions of coordinate 980 reference systems. 982 To identify the elements that are defined in this schema, a URI is 983 used. This document is not identified by a URL, instead it uses 984 the URN that is registered for identification of the schema 985 "urn:ietf:params:xml:schema:geopriv:indoor". 987 988 998 1002 1003 1005 Indoor Location for PIDF-LO 1007 1009 1010 1011 A dictionary including a Cartesian Coordinate System and 1012 units of measure for a system of indoor location. 1013 1014 Indoor Location 1016 1017 1018 1019 3-D Cartesian CS 1020 1021 1023 X-Axis 1024 x 1027 east+o 1030 1031 1032 1033 1035 Y-Axis 1036 y 1039 north+o 1042 1043 1044 1045 1047 Z-Axis 1048 z 1051 up 1054 1055 1056 1057 1059 1060 1061 1062 2-D Cartesian CS 1063 1064 1065 1066 1068 1069 1070 1071 1072 The pixel is the basic unit of measure used in images. 1073 1074 pixel 1076 image units 1077 px 1080 1082 1083 1085 1086 1087 1088 1089 A mapping of pixels to a length in metres. 1090 1091 pixels per metre 1093 pixels per meter 1095 1096 mapping of local length to physical length 1097 1098 pxpm 1101 1102 1104 1105 1106 1107 1109 1110 This schema defines a location representation that allows for 1111 the trivial creation of a locally-defined coordinate reference 1112 system; specifically one that is based on a local map image. 1113 1115 1117 1118 1119 1122 1125 1126 1127 1128 1129 1131 1133 1135 1136 1137 1138 1139 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1152 1153 1154 1155 1156 1157 1158 1160 1162 1163 1164 1165 1166 1167 1169 1171 1172 1174 1175 1176 1178 1179 1180 1181 1182 1184 1185 1186 1187 1188 1190 1191 1192 1193 1194 1195 1197 1198 1199 1200 1201 1203 11. Security Considerations 1205 This document describes information that is intended for inclusion 1206 within a location object, specifically a PIDF-LO. The security 1207 concerns relating to the use of a location object are described in 1208 [RFC4119]. Further security and privacy considerations are included 1209 in [I-D.ietf-geopriv-arch]. No further considerations are known to 1210 apply. 1212 12. IANA Considerations 1214 This section registers a URN for the identification of XML elements 1215 for describing a local CRS, plus the schema that defines those 1216 elements. 1218 12.1. URN Sub-Namespace Registration for 1219 'urn:ietf:params:xml:ns:geopriv:indoor' 1221 This section registers a new XML namespace, 1222 "urn:ietf:params:xml:ns:geopriv:indoor", per the guidelines in 1223 [RFC3688]. 1225 URI: urn:ietf:params:xml:ns:geopriv:indoor 1227 Registrant Contact: IETF, GEOPRIV working group, 1228 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1230 XML: 1232 BEGIN 1233 1234 1236 1237 1238 GEOPRIV: Indoor location representation 1239 1240 1241

Namespace for Indoor location representation

1242

urn:ietf:params:xml:ns:geopriv:indoor

1243 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1244 with the RFC number for this specification.] 1245

See RFCXXXX

1246 1247 1248 END 1250 12.2. XML Schema Registration 1252 This section registers an XML schema as per the guidelines in 1253 [RFC3688]. 1255 URI: urn:ietf:params:xml:schema:geopriv:indoor 1257 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1258 Martin Thomson (martin.thomson@andrew.com). 1260 Schema: The XML for this schema can be found in Section 10 of this 1261 document starting with "". 1264 13. Acknowledgements 1266 Cullen Jennings provided valuable feedback on the use of maps with 1267 early versions of this document. 1269 14. References 1270 14.1. Normative References 1272 [RFC2119] Bradner, S., "Key words for use in 1273 RFCs to Indicate Requirement 1274 Levels", BCP 14, RFC 2119, 1275 March 1997. 1277 [RFC4119] Peterson, J., "A Presence-based 1278 GEOPRIV Location Object Format", 1279 RFC 4119, December 2005. 1281 [RFC5139] Thomson, M. and J. Winterbottom, 1282 "Revised Civic Location Format for 1283 Presence Information Data Format 1284 Location Object (PIDF-LO)", 1285 RFC 5139, February 2008. 1287 [RFC5491] Winterbottom, J., Thomson, M., and 1288 H. Tschofenig, "GEOPRIV Presence 1289 Information Data Format Location 1290 Object (PIDF-LO) Usage 1291 Clarification, Considerations, and 1292 Recommendations", RFC 5491, 1293 March 2009. 1295 [OGC.GeoShape] Thomson, M. and C. Reed, "GML 1296 3.1.1 PIDF-LO Shape Application 1297 Schema for use by the Internet 1298 Engineering Task Force (IETF)", 1299 OGC Best Practice 06-142r1, 1300 Version: 1.0, April 2007. 1302 [W3C.REC-xlink-20010627] DeRose, S., Orchard, D., and E. 1303 Maler, "XML Linking Language 1304 (XLink) Version 1.0", World Wide 1305 Web Consortium Recommendation REC- 1306 xlink-20010627, June 2001, . 1310 14.2. Informative References 1312 [RFC3688] Mealling, M., "The IETF XML 1313 Registry", BCP 81, RFC 3688, 1314 January 2004. 1316 [RFC3986] Berners-Lee, T., Fielding, R., and 1317 L. Masinter, "Uniform Resource 1318 Identifier (URI): Generic Syntax", 1319 STD 66, RFC 3986, January 2005. 1321 [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., 1322 Portele, C., and A. Whiteside, 1323 "Geographic information - 1324 Geography Markup Language (GML)", 1325 OpenGIS 03-105r1, April 2004, . 1329 [I-D.ietf-geopriv-arch] Barnes, R., Lepinski, M., Cooper, 1330 A., Morris, J., Tschofenig, H., 1331 and H. Schulzrinne, "An 1332 Architecture for Location and 1333 Location Privacy in Internet 1334 Applications", 1335 draft-ietf-geopriv-arch-01 (work 1336 in progress), October 2009. 1338 [I-D.thomson-geopriv-uncertainty] Thomson, M. and J. Winterbottom, 1339 "Representation of Uncertainty and 1340 Confidence in PIDF-LO", draft- 1341 thomson-geopriv-uncertainty-03 1342 (work in progress), June 2009. 1344 Appendix A. Calculating WGS84 ECEF Up, North and East Vectors 1346 Unit vectors corresponding to Up, North and East from a given point 1347 are used for transformation of coordinates between WGS84 and the 1348 local CRS. These vectors are provided in the Cartesian coordinate 1349 system used by WGS84: the Earth-Centered, Earth-Fixed (ECEF) variant 1350 of WGS84 (X, Y, Z). 1352 These vectors change depending on location, but depend only on 1353 latitude and longitude; the altitude of the point has no affect on 1354 the vectors. 1356 The following values are used (where sin(x) is the sine function of x 1357 and cos(x) the cosine function): coslat = cos(latitude); sinlat = 1358 sin(latitude); coslng = cos(longitude); sinlng = sin(longitude). 1360 When calculating the orientation of Up, North and East vectors in 1361 Earth-Centered, Earth-Fixed (ECEF) coordinates, inverse flattening of 1362 the WGS84 ellipsoid is not considered. These vectors are: 1364 East = [ -sinlng ; coslng ; 0 ] 1365 North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ] 1366 Up = [ coslat * coslng ; coslat * sinlng ; sinlat ] 1368 These are all orthogonal unit vectors, therefore the matrix they form 1369 is also orthogonal. 1371 The Up vector plus the ECEF coordinates of a point defines the plane 1372 of the horizontal at that point: 1374 (x - c[x]) * Up[x] + (y - c[y]) * Up[y] + (z - c[z]) * Up[z] = 0 1376 Authors' Addresses 1378 Martin Thomson 1379 Andrew Corporation 1380 Andrew Building (39) 1381 Wollongong University Campus 1382 Northfields Avenue 1383 Wollongong, NSW 2522 1384 AU 1386 EMail: martin.thomson@andrew.com 1388 James Winterbottom 1389 Andrew Corporation 1390 Andrew Building (39) 1391 Wollongong University Campus 1392 Northfields Avenue 1393 Wollongong, NSW 2522 1394 AU 1396 EMail: james.winterbottom@andrew.com