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