[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

GEOPRIV                                                       M. Thomson
Internet-Draft                                           J. Winterbottom
Intended status: Standards Track                      Andrew Corporation
Expires: June 3, 2010                                  November 30, 2009


  Locations with Locally-Defined Coordinate Reference Systems for the
      Presence Information Data Format - Location Object (PIDF-LO)
                draft-thomson-geopriv-indoor-location-01

Abstract

   A method is described for constructing a Presence Information Data
   Format - Location Object (PIDF-LO) document that contains location
   information using a locally-defined coordinate reference system
   (CRS).  This form of representation allows for use of locally-defined
   coordinates with potential advantages for improved accuracy and
   usability in local context, in particular location applications that
   operate indoors.  A framework for defining a local CRS is provided.
   A process for transformation of coordinates defined in the local CRS
   and the widely used World Geodetic System 1984 (WGS84) CRS is
   defined.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 3, 2010.

Copyright Notice




Thomson & Winterbottom    Expires June 3, 2010                  [Page 1]


Internet-Draft               Indoor Location               November 2009


   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.







































Thomson & Winterbottom    Expires June 3, 2010                  [Page 2]


Internet-Draft               Indoor Location               November 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Solution . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Example Use Case . . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Generating Local Location Information  . . . . . . . . . . . .  7
     4.1.  Local Map Image  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Local Coordinate Reference System  . . . . . . . . . . . . . .  8
     5.1.  Cartesian Coordinate System  . . . . . . . . . . . . . . .  9
     5.2.  Local or Indoor Datum  . . . . . . . . . . . . . . . . . .  9
       5.2.1.  Anchor Location  . . . . . . . . . . . . . . . . . . . 10
       5.2.2.  Orientation  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Local Map Presentation . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Image Coordinates  . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Map Image  . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Reference Location . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Pixel Offset . . . . . . . . . . . . . . . . . . . . . . . 14
     6.5.  Scaling  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       6.5.1.  Map Projections  . . . . . . . . . . . . . . . . . . . 14
   7.  Coordinate Transformation  . . . . . . . . . . . . . . . . . . 15
     7.1.  Conversion from WGS84 to Local CRS . . . . . . . . . . . . 15
     7.2.  Conversion from Local CRS to WGS . . . . . . . . . . . . . 17
     7.3.  Transformation Matrix  . . . . . . . . . . . . . . . . . . 18
     7.4.  Managing Uncertainty . . . . . . . . . . . . . . . . . . . 18
     7.5.  Angles of Orientation  . . . . . . . . . . . . . . . . . . 19
   8.  Example PIDF-LO  . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  GML Definitions  . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Units of Measure . . . . . . . . . . . . . . . . . . . . . 21
     9.2.  Code Space Definitions . . . . . . . . . . . . . . . . . . 22
   10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     12.1. URN Sub-Namespace Registration for
           'urn:ietf:params:xml:ns:geopriv:indoor'  . . . . . . . . . 27
     12.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 28
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     14.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Appendix A.  Calculating WGS84 ECEF Up, North and East Vectors . . 30









Thomson & Winterbottom    Expires June 3, 2010                  [Page 3]


Internet-Draft               Indoor Location               November 2009


1.  Introduction

   Providing location information in indoor environments presents new
   sets of technical challenges and use cases for location determination
   and representation.  For use indoors, location information that is in
   a form specific to that locality can be both more accurate and more
   usable.

   The ability to specify relative coordinates simplifies the use of
   local applications, especially local mapping or navigation
   applications, which often rely on floor plan images or provide
   directions based on fixtures of the local environment.

   Within the confines of a building, or in any local context, location
   information might be determined in relation to fixtures in that
   environment.  This might provide location information that is highly
   accurate within a local region, but errors are added if conversion to
   a globally useful form like World Geodetic System 1984 (WGS84) are
   required.

      For instance, wireless positioning systems within a building might
      provide excellent accuracy in relation to the wireless
      transmitters.  However, in converting locations in a local
      reference frame to a globally applicable systems such as WGS84,
      these systems encounter difficulties.

      On the other hand, Global Navigation Satellite Systems (GNSS),
      which are widely used to generate location information, operate
      poorly indoors or anywhere an unobstructed view of the sky cannot
      be found.

   For these cases and others like them, avoiding conversion steps
   ensures that unnecessary errors are not introduced.

1.1.  Solution

   A means to describe a location in relation to a fixed reference is
   defined.  These locations use the forms defined in [OGC.GeoShape],
   using a custom coordinate reference system (CRS).

   A form for defining a local CRS is described, such that locations in
   that CRS can be trivially translated to and from the World Geodetic
   System 1984 (WGS84) CRS used in PIDF-LO.  This allows for location to
   be expressed in a canonical form, while preserving the location
   information for use in the local context.

   Guidelines are further provided for constructing a Presence
   Information Data Format - Location Object (PIDF-LO) document



Thomson & Winterbottom    Expires June 3, 2010                  [Page 4]


Internet-Draft               Indoor Location               November 2009


   [RFC4119] so that existing applications and consumers of location
   information are able to operate.  These guidelines are based on those
   described in RFC 5491 [RFC5491].

1.2.  Example Use Case

   A shopper uses the information contained in a PIDF-LO to identify the
   location of a store in a mall.  The geodetic location information
   [OGC.GeoShape] or civic address information [RFC5139] helps the
   shopper identify the location of the mall.

   The relative, or indoor, location representation helps the shopper
   find the store within the mall.  This information can be used
   together with a map of the mall, providing information in a form that
   is more readily usable to the shopper.  The location of the store or
   the shopper can be overlaid on the provided map, aiding in finding
   the store.

   Transformation from WGS84 to the local CRS allows the shopper to use
   location determination methods that are not aware of the local CRS.
   Conversely, the location in the local CRS can be transformed into a
   geodetic location for use outside of the mall, or for applications
   that are unaware of the local context.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Overview

   A location in a user-defined CRS is included in a PIDF-LO document as
   shown in Figure 1, which includes the high-level elements involved.

















Thomson & Winterbottom    Expires June 3, 2010                  [Page 5]


Internet-Draft               Indoor Location               November 2009


     <presence entity="pres:...">

       <tuple id="geodetic"><status><geopriv>  * geodetic tuple
         <location-info>
           <Circle srsName="urn:..." .../>     * geodetic location
         </location-info> ...
       </geopriv></status></tuple>

       <tuple id="indoor"><status><geopriv>    * indoor tuple
         <location-info>

           <Circle srsName="#indoorCRS" .../>  * indoor location

           <EngineeringCRS ...>                * local CRS
             <srsName>#indoorCRS</srsName>
             <usesCS .../>                     * coordinate system
             <usesEngineeringDatum>
               <IndoorDatum .../>              * local datum
             </usesEngineeringDatum>
           </EngineeringCRS>

           <mapImage .../>                     * image information
         </location-info> ...
       </geopriv></status></tuple>

     </presence>

                   Figure 1: PIDF-LO Structure Overview

   Two tuples are included in the PIDF-LO.  One containing geodetic
   location information, the second containing locally defined
   coordinates.  Depending on how the location generator operates,
   transformation (Section 7) might be used to construct one or other
   location element.

   The first "tuple" (or "device" or "person") contains geodetic
   information [OGC.GeoShape].  This first tuple uses a WGS84 CRS, so
   that the information is usable outside of the local context.

      Aside from being required by [RFC5491], this ensures that overly
      simplistic processors that rely on tuple ordering do not
      erroneously assume the use of WGS84 with the subsequent shape
      information.

   A second "tuple" includes location information using a Geography
   Markup Language (GML) [OGC.GML-3.1.1] geometry element, but using a
   custom, geo-referenced CRS in place of the WGS84 reference that is
   used for the geodetic shape.  A formal definition of the CRS is



Thomson & Winterbottom    Expires June 3, 2010                  [Page 6]


Internet-Draft               Indoor Location               November 2009


   included in the tuple with the shape.

   The CRS is defined only within the scope of the PIDF-LO.  A URI
   fragment identifier is used to identify the CRS "srsName" parameters
   that reference the CRS.

   A reference to a GML dictionary containing the CRS MAY be used in
   place of the fragment identifier used in this document.  An "http:"
   or "https:" URI MUST be used for this purpose unless an alternative
   scheme is known to be supported or recognized by recipients of the
   PIDF-LO.  Authors of PIDF-LO documents that rely on providing a
   reference to the CRS need to have some assurance that all potential
   recipients of the location information are either able to resolve the
   reference or do not require the local information.

   This document describes a means of generating a geodetic location
   from a locally defined location, providing that the reference point
   of the local CRS is specified as a geodetic location.  If a civic
   address is used as a reference point, other information is needed to
   ensure that the location information is useful outside of the local
   context.

4.  Generating Local Location Information

   When creating location information for use in a local context, a
   coordinate reference system definition is required.  Once the CRS is
   defined, the shapes from [OGC.GeoShape] can be used with an "srsName"
   attribute that references the newly defined CRS, rather than WGS84.

   The locally-defined shapes only differ from those in [OGC.GeoShape]
   by the CRS identifier used:

     <gs:Circle srsName="#indoorCRS"> <!-- Local CRS -->
       <gml:pos>47.5 22</gml:pos>
       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">2.4
       </gs:radius>
     </gs:Circle>

   A GML "EngineeringCRS" element is used to define a local coordinate
   reference system.  An engineering CRS is formed of an identifier and
   name, a coordinate system and a datum.

   The "gml:id" attribute of "EngineeringCRS" contains any valid XML
   name.  The "srsName" includes a URI fragment [RFC3986] that refers to
   this identifier; this value is used in the "srsName" in place of a
   WGS84 CRS URI.  No "codeSpace" attribute is included.

     <gml:EngineeringCRS gml:id="indoorCRS">



Thomson & Winterbottom    Expires June 3, 2010                  [Page 7]


Internet-Draft               Indoor Location               November 2009


       <gml:srsName>#indoorCRS</gml:srsName>

   The CRS then needs a reference to the coordinate system defined in
   this document (Section 5.1).  This reference is provided using an
   XLink [W3C.REC-xlink-20010627] attribute:

     <gml:usesCS
         xlink:href="urn:ietf:params:xml:schema:geopriv:indoor#cs2d"/>

   An engineering datum is used to define how the coordinate system then
   relates to the local environment.  This uses the "IndoorDatum"
   element defined in this document (Section 5.2).  This uses similar
   identification to the CRS definition:

     <indoor:IndoorDatum gml:id="officeDatum"
         xmlns:indoor="urn:ietf:params:xml:ns:geopriv:indoor">
       <gml:datumName>#officeDatum</gml:datumName>
       ...
     </indoor:IndoorDatum>

   An indoor datum requires a reference point (Section 5.2.1) and an
   orientation (Section 5.2.2) angle.  The reference point is described
   using either a geodetic shape [OGC.GeoShape], a civic address
   [RFC5139], or both elements according to the rules in RFC 5491
   [RFC5491].  A complete example document is included in Section 8.

4.1.  Local Map Image

   An optional map image can be provided to be used in presenting the
   local information.  If a map image is used as a reference, then pixel
   coordinates from an image can then be used directly.

     <indoor:localMap>
       <indoor:image .../>
       <indoor:referenceLocation .../>
       <indoor:offset .../>
       <indoor:scale .../>
     </indoor:localMap>

   The manner in which a map image can be related to the local
   coordinate system is described in Section 6.

5.  Local Coordinate Reference System

   A coordinate reference system (CRS) requires the definition of a
   coordinate system, and a description of how that coordinate system
   relates to a particular model of physical space.




Thomson & Winterbottom    Expires June 3, 2010                  [Page 8]


Internet-Draft               Indoor Location               November 2009


   The coordinate system used in relation to images is defined in this
   document.  All images use the same coordinate system.  Two coordinate
   systems are defined, identified by the URNs:

   o  urn:ietf:params:xml:schema:geopriv:indoor#cs3d

   o  urn:ietf:params:xml:schema:geopriv:indoor#cs2d

   The datum that establishes the origin for the coordinate system is
   defined during construction of the PIDF-LO.  The datum is anchored to
   a specific location.

   Section 8 shows an example definition of an coordinate reference
   system that include the definition of a location-specific datum that
   corresponds to a specific anchor point.

5.1.  Cartesian Coordinate System

   A custom coordinate reference system (CRS) is defined for use in
   representing indoor locations.  This allows positions to be expressed
   in relation to a floor plan or map.

   Section 10 includes the definition of two Cartesian coordinate
   systems.  The two-dimensional Cartesian coordinate system is
   identified by the URN
   "urn:ietf:params:xml:schema:geopriv:indoor#cs2d".  The three-
   dimensional Cartesian coordinate system is identified by the URN
   "urn:ietf:params:xml:schema:geopriv:indoor#cs3d".

   The coordinate system described is positively oriented (that is, it
   is right-handed).  The two-dimensional coordinate system uses x- and
   y-axes to represent coordinates.  The three-dimensional coordinate
   system adds a z-axis.

5.2.  Local or Indoor Datum

   The image datum establishes a relationship between the coordinate
   system and a physical space.

   An extension of the GML "ImageDatum" type is used to define a datum
   precisely.  This definition allows for transformation between the
   local CRS and WGS84.

   Note:  WGS84 coordinates are specified in the order of latitude,
      longitude, altitude.  The local coordinate system is specified in
      order: x, y, z.  With an orientation of zero the x-axis roughly
      corresponds to longitude, and the y-axis to the inverse of
      latitude.  Following the process described in Section 7 ensures



Thomson & Winterbottom    Expires June 3, 2010                  [Page 9]


Internet-Draft               Indoor Location               November 2009


      that this "reordering" does not introduce errors.

5.2.1.  Anchor Location

   This engineering datum identifies a point in space as the location of
   the origin.  This can be objectively specified using WGS84
   coordinates in a geodetic shape [OGC.GeoShape]; alternatively, it can
   be subjectively specified using a civic address [RFC5139].  Both
   forms of location data MAY be included.

   The form of reference location that is used depends on what purpose
   the information is intended to serve.  A geodetic reference location
   provides a basis for unambiguous transformation between locations in
   the locally-defined CRS and WGS84.  Civic addresses are often more
   readily usable by people.

   The "anchor" element allows for the inclusion of any form of GML
   geometry.  Geodetic shapes produced by implementations conforming to
   this specification MUST use one of the forms described in
   [OGC.GeoShape].

   A single reference point can derived from the provided location.  The
   centroid of the geodetic shape [I-D.thomson-geopriv-uncertainty] is
   used if the origin is included with uncertainty.  This point is used
   to anchor the local datum, as well as establishing the plane of the
   horizontal.

   The means for determining a point from a civic address is not
   defined.  The "LOC" field of the civic address can be used to provide
   a textual description of the reference point.

5.2.2.  Orientation

   In many cases, it is convenient to use a rotated coordinate system in
   the local context.  It is rare that a building is neatly aligned with
   North.  Within the local context, directions are made in relation to
   the building, not the cardinal directions.

   Maps for use within structures are only rarely produced with geodetic
   North toward the top of the image.  Building maps are often oriented
   so that the majority of features do not appear at irregular angles on
   the map.

   The "orientation" element provides a way to use locally useful
   coordinates.  This element contains a single angular measure that
   describes how the local coordinate system is oriented in relation to
   the North and East directions from the reference point (see
   Appendix A).



Thomson & Winterbottom    Expires June 3, 2010                 [Page 10]


Internet-Draft               Indoor Location               November 2009


   The positive x-axis corresponds to an Easting vector at the anchor
   point, rotated in a clockwise direction (that is, Northing to
   Easting) about the vertical by the orientation angle.  Similarly, the
   y-axis corresponds to a rotated Northing vector.

           ^ North
           |
           |        _
           +--._    /\ y-axis
           |    `. /   (north+o)
           |      /
           |     /
           |    /
           |   /
           |  /
           | /
           |/                    East
           o-------------+--------->
            `-._         |
                `-._     ; orientation
                    `-._/
                        `-._
                            `_|  x-axis
       [ Up == z-axis ]         (east+o)

   The z-axis in the three-dimensional coordinate system is oriented
   directly upwards from the plane tangential to the WGS84 ellipsoid at
   the anchor point.  This is unaffected by the orientation angle.

6.  Local Map Presentation

   A map image can be referred to using the "localMap" element.  This
   allows for the locally defined location to be presented with
   additional context.

   Image information is placed in the "location-info" element after the
   shape information and CRS.

6.1.  Image Coordinates

   A position on an image generally uses a coordinate system with an
   origin in the upper left.  For a two-dimensional image, a columns-
   axis increases to the right and a rows-axis increases towards the
   bottom of the image.

   This left-handed coordinate system - inherited from the path that the
   beam in a Cathode-ray tube follows - does not directly map to the
   axes used in the local, Cartesian coordinate system.  The rows-axis



Thomson & Winterbottom    Expires June 3, 2010                 [Page 11]


Internet-Draft               Indoor Location               November 2009


   is in the opposite direction to the y-axis.

                      (local coordinates)
                  ^
                  |
                y-axis
                  |
                  |
                      ---- x-axis ---->
               O------------------------------+
               |    ---- columns-axis ---->   |
               |  |                           |
               |  |                           |
               | rows-axis                    |
               |  |                           |
               |  v                           |
               |      (image coordinates)     |
               +------------------------------+

                           Figure 2: Image Axes

   If a left-handed coordinate system is used in an image, the scale
   (Section 6.5) element can be used to convert negative y-axis values
   into positive rows-axis values.  A negative value for the rows/y
   value (the second value) can be used for this purpose.

   Some image types specifically defined how coordinates are interpreted
   for the image.  However, if this is not specified or unknown for the
   image type and it is necessary to place a point with sub-pixel
   precision, whole integer values in image coordinates are found at the
   low-valued corner of the referenced pixel.  This is usually the top
   left corner of the pixel where row/column coordinates are used.



















Thomson & Winterbottom    Expires June 3, 2010                 [Page 12]


Internet-Draft               Indoor Location               November 2009


   For instance, the pixel at [5,13] in the following covers the column
   range 5.0 to 6.0 and the row range from 13 to 14.

           4        5        6        7
           |        |        |        |
      12 --+--------+--------+--------+-
           |        |        |        |
           |        |        |        |
           |        |        |        |
      13 --+--------+--------+--------+-
           |        |        |        |
           |        | [5,13] |        |
           |        |        |        |
      14 --+--------+--------+--------+-
           |        |        |        |
           |        |        |        |
           |        |        |        |
      15 --+--------+--------+--------+-
           |        |        |        |

                      Whole Integer Image Coordinates

6.2.  Map Image

   The optional "image" element includes an image, usually a map of the
   locality.  This image might be used to display the associated
   location information to a user.

   Rather than include an image inline, this uses XLink
   [W3C.REC-xlink-20010627] to reference an image document.  The
   "xlink:href" attribute contains a URL for the image.  An "http:" or
   "https:" URI MUST be used unless the location generator is able to
   ensure that authorized recipients of this data are able to use other
   URI schemes.

6.3.  Reference Location

   The "referenceLocation" element describes the reference location used
   to place (and orient) the image in space.  This can be specified in
   the same way that the anchor location (Section 5.2.1) for the datum
   is specified using a geodetic shape or civic address.

   If a local CRS is defined in the same document, the reference point
   SHOULD refer the origin of the coordinate reference system, using the
   "crsOrigin" element.  This references the anchor point used in the
   CRS definition, saving unnecessary duplication of this information.

   The rows-axis of the image is either along the negative y-axis of a



Thomson & Winterbottom    Expires June 3, 2010                 [Page 13]


Internet-Draft               Indoor Location               November 2009


   Cartesian CRS or Southing from the reference point.  The columns-axis
   of the image is along the positive y-axis or Easting from the
   reference point.  Any vertical axis is oriented along the z-axis or
   directly up from the reference point.  See Appendix A for details on
   how to determine North, East and Up vectors from an arbitrary point.

6.4.  Pixel Offset

   The anchor point is matched to a point on the image, thus
   establishing a common point in both coordinate reference systems.
   The "offset" element includes the coordinates of the reference point
   in the image.

6.5.  Scaling

   The "scale" element includes a value in pixels per meter that
   describes how coordinates in the local datum, specified in meters,
   are translated to coordinates on the image at the reference point.

   A scaling factor is provided for each axis in the coordinate system.
   For a two-dimensional coordinate system, two values are included to
   allow for different scaling along the x/columns- and y/rows-axes
   independently.  For a three-dimensional coordinate system, three
   values are specified for the x/columns-, y/rows- and z/vertical-axes.

   Alternatively, a single scaling value MAY be used to apply the same
   scaling factor to all coordinate components (x/columns- and y/rows-
   axes, and optionally the z/vertical-axis).

   A negative value for the y/rows-axis scaling value can be used to
   account for the change in direction between the y-axis and the rows
   axis, as shown in Figure 2.

6.5.1.  Map Projections

   The method used to orient and scale a map image is limited in
   applicability.  This method does not account for distortion produced
   by the curvature of the Earth.  That is, it does not allow for the
   additional complexity that would be necessary to accomodate different
   map projection methods.  The coordinate space used is strictly
   Cartesian.

   The Cartesian coordinate system suits maps with a orthographic
   projection centered at the reference point.  It also suits
   architectural drawings and diagrams that also do not account for the
   curvature of the Earth.

   This does not necessarily prevent the use of alternative map



Thomson & Winterbottom    Expires June 3, 2010                 [Page 14]


Internet-Draft               Indoor Location               November 2009


   projections.  For other map projections, the scaling factor changes
   as the distance from the reference point increases.

   Over small distances, an orthographic projection might be assumed.
   Any errors introduced by this simplication might be acceptable for an
   application.  This simplication is only appropriate for maps that
   cover small distances or where any errors resulting from use of
   different map projections are acceptable.

7.  Coordinate Transformation

   It is often important that location information be provided that can
   be used in a global context, as well as the local context.  This
   section describes how shapes can be transformed between the WGS84 CRS
   and the local CRS.

   A single point is selected in the image coordinate reference system.
   This might be the origin of the image (0, 0), or any other point.
   The corresponding point in WGS84 (latitude, longitude, altitude) is
   also identified.

   Selecting a point in each coordinate system establishes a reference
   point: an origin point.  When converting, all coordinates are
   expressed relative to the corresponding point in the same coordinate
   system.

7.1.  Conversion from WGS84 to Local CRS

   To convert coordinates specified in WGS84 to coordinates specified in
   the local CRS use the following algorithm:

   1.  If the coordinates do not include altitude, add an altitude of
       zero.  This will be removed from the final result, but an
       altitude value is required for this algorithm.

   2.  Convert the WGS84 (latitude, longitude, altitude) coordinates to
       WGS84 ECEF (X, Y, Z) values.  One commonly used algorithm for
       this is documented in [I-D.thomson-geopriv-uncertainty].

   3.  If necessary, find the centroid of the reference location,
       specified in the "anchor" element, in WGS84 ECEF (X, Y, Z)
       coordinates.  Algorithms for this are documented in
       [I-D.thomson-geopriv-uncertainty].

   4.  Subtract the ECEF reference location from the ECEF coordinates to
       get a relative position vector for the coordinates.





Thomson & Winterbottom    Expires June 3, 2010                 [Page 15]


Internet-Draft               Indoor Location               November 2009


   5.  Multiply the resulting relative position by the forward
       transformation matrix described in Section 7.3.  This gives
       distances in meters for each of the axes of the local coordinate
       system.

   6.  If altitude was not originally provided, remove any vertical or
       z-axis component.

   7.  If the reference location contains uncertainty, add this
       uncertainty to any uncertainty in the original location, see
       Section 7.4.

   The results can be summarized as:

      C[local] = R * T[0] * (C[ecef] - R[ecef])

   Where all coordinates are expressed as column vectors and "*" is the
   matrix product.

   The WGS84 reference point also establishes a reference plane for the
   image.  The reference plane is the plane of the horizontal at that
   point - the plane tangential to the WGS84 ellipsoid at the reference
   point.  This plane, along with the orientation angle, are used to
   create a transformation matrix.

   Coordinates can then be plotted on the map image by applying the
   following process:

   1.  Multiply each component of the vector by the scaling factor,
       specified in the "scale" element, to obtain values in pixels.

   2.  Add the resulting value to the image offset, specified in the
       "offset" element, to obtain the coordinates in the image.

   If the image uses a different reference point to the origin of the
   local CRS, then the coordinates must first be transformed into
   coordinates in a local CRS that is centered about that reference
   point.

   The results can be summarized as:

      C[image] = offset + scale .* C[local]

   Where ".*" is the Hadamard or entrywise product.







Thomson & Winterbottom    Expires June 3, 2010                 [Page 16]


Internet-Draft               Indoor Location               November 2009


7.2.  Conversion from Local CRS to WGS

   To convert coordinates specified in the local CRS to coordinates
   specified in WGS84 use the following algorithm:

   1.  If the coordinates do not include a vertical or z-axis component,
       set this value to zero.

   2.  Multiply the resulting relative position by the reverse
       transformation matrix described in Section 7.3 to get a vector
       relative to the reference location.

   3.  If necessary, find the centroid of the reference location,
       "origin", in WGS84 ECEF (X, Y, Z) coordinates.

   4.  Add the ECEF reference location to the ECEF coordinates.

   5.  Convert the WGS84 ECEF (X, Y, Z) coordinates to WGS84 (latitude,
       longitude, altitude) values.

   6.  If vertical or z-axis values were not provided, remove the
       altitude value.

   7.  If the reference location contains uncertainty, add this
       uncertainty to any uncertainty in the original location.

   The results can be summarized as:

      C[ecef] = transpose(R * T[0]) * (C[local]) + R[ecef]

   Where "transpose(...)" signifies the matrix transpose.

   If image coordinates are known, the local coordinates can be found by
   first following these steps:

   1.  Subtract the image offset from the coordinate values.

   2.  Divide each component of the vector by the scaling factor.

   The results can be summarized as:

      C[local] = (1/scale) .* (C[image] - offset)

   Where "1/scale" is 1 divided by the scaling factor.







Thomson & Winterbottom    Expires June 3, 2010                 [Page 17]


Internet-Draft               Indoor Location               November 2009


7.3.  Transformation Matrix

   The transformation matrix used to convert coordinates between WGS84
   and the local CRS uses the centroid of the origin location, contained
   in the "origin" element.

   The transformation matrix is formed from the North, East and Up
   vectors from the origin location.  Appendix A describes how to
   determine these vectors in WGS84 ECEF coordinates:

      East  = [ -sinlng          ; coslng           ; 0      ]
      North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
      Up    = [ coslat * coslng  ; coslat * sinlng  ; sinlat ]

   This is used directly to form the following transformation matrix for
   the case where the orientation is zero:

             [ -sinlng          ; coslng           ; 0      ]
      T[0] = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
             [ coslat * coslng  ; coslat * sinlng  ; sinlat ]

   The orientation of the map, included in the "orientation" element,
   affects the x-axis and y-axis parts of this matrix.  The rotation
   matrix is a counter-clockwise rotation matrix, as follows:

          [ cos(orientation) ; -sin(orientation) ; 0 ]
      R = [ sin(orientation) ; cos(orientation)  ; 0 ]
          [ 0                ; 0                 ; 1 ]

   Both "R" and "T[0]" perform rotations.  The final transformation
   matrix is then the product of the rotation matrix and the coordinate
   transformation matrix.  This gives the following orthonormal
   coordinate transformation matrix.

      T = R * T[0]

   When transforming from local coordinates to WGS84, the transformation
   matrix is transposed to find its inverse.

7.4.  Managing Uncertainty

   The WGS84 origin location MAY include uncertainty if that location is
   not sufficiently accurate.  In this case, the centroid of the
   uncertainty region is used as the origin point.  The uncertainty in
   this location increases any uncertainty when performing a
   transformation.

   An increase to uncertainty is applied when transforming both to and



Thomson & Winterbottom    Expires June 3, 2010                 [Page 18]


Internet-Draft               Indoor Location               November 2009


   from WGS84.  Repeated transformations can increase uncertainty
   indefinitely.

   Converting the origin location and the target shape to a Circle or
   Sphere prior to transformation simplifies the management of
   uncertainty.  The resulting uncertainty radius is the sum of the
   radius from the original shape, plus the radius from the origin
   location.

7.5.  Angles of Orientation

   Translation of Ellipse, Ellipsoid and ArcBand shapes requires that
   the included angle measures are rotated.  When translating from the
   local coordinate reference system, the orientation of the image datum
   is added to the angle.  The orientation of the image datum is
   subtracted when translating from WGS84 coordinates.

8.  Example PIDF-LO

   The following example PIDF-LO document contains geodetic location in
   the first tuple, followed by a similar location in the local CRS.  A
   map image is also included.  All other optional elements are omitted
   from this example.

     <presence
         xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         xmlns:indoor="urn:ietf:params:xml:ns:geopriv:indoor"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         entity="pres:ae3be8585902e2253ce2@lis.example">

       <tuple id="geodeticLocation">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-34.407124 150.882673</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">10
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
           </gp:geopriv>
         </status>
       </tuple>



Thomson & Winterbottom    Expires June 3, 2010                 [Page 19]


Internet-Draft               Indoor Location               November 2009


       <tuple id="indoorLocation">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="#officeCRS">
                 <gml:pos>47.5 22</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">2.4
                 </gs:radius>
               </gs:Circle>

               <gml:EngineeringCRS gml:id="officeCRS">
                 <gml:srsName>#officeCRS</gml:srsName>
                 <gml:usesCS
     xlink:href="urn:ietf:params:xml:schema:geopriv:indoor#cs2d"/>
                 <gml:usesEngineeringDatum>
                   <indoor:IndoorDatum gml:id="officeDatum">
                     <gml:datumName>#officeDatum</gml:datumName>
                     <indoor:anchor>
                       <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                         <gml:pos>-34.407168 150.882533</gml:pos>
                         <gs:radius uom="urn:ogc:def:uom:EPSG::9001">5
                         </gs:radius>
                       </gs:Circle>
                       <ca:civicAddress xml:lang="en">
                         <ca:country>AU</ca:country>
                         <ca:A1>NSW</ca:A1>
                         <ca:A3>Wollongong</ca:A3>
                         <ca:A4>Gwynneville</ca:A4>
                         <ca:RD>Northfields</ca:RD>
                         <ca:STS>Avenue</ca:STS>
                         <ca:LMK>University of Wollongong</ca:LMK>
                         <ca:LOC>Director's Office</ca:LOC>
                         <ca:FLR>2</ca:FLR>
                         <ca:NAM>Andrew Corporation</ca:NAM>
                         <ca:PC>2500</ca:PC>
                         <ca:BLD>39</ca:BLD>
                         <ca:PLC>office</ca:PLC>
                       </ca:civicAddress>
                     </indoor:anchor>
                     <indoor:orientation
                         uom="urn:ogc:def:uom:EPSG::9102">8.4
                     </indoor:orientation>
                   </indoor:IndoorDatum>
                 </gml:usesEngineeringDatum>
               </gml:EngineeringCRS>

               <indoor:localMap>
                 <indoor:image xlink:href="http://example.com/map.png"/>



Thomson & Winterbottom    Expires June 3, 2010                 [Page 20]


Internet-Draft               Indoor Location               November 2009


                 <indoor:referenceLocation>
                   <indoor:crsOrigin xlink:href="#officeCRS"/>
                 </indoor:referenceLocation>
                 <indoor:offset
     uom="urn:ietf:params:xml:schema:geopriv:indoor#px">374 184
                 </indoor:offset>
                 <indoor:scale
     uom="urn:ietf:params:xml:schema:geopriv:indoor#pxpm">20
                 </indoor:scale>
               </indoor:localMap>
             </gp:location-info>

             <gp:usage-rules/>
           </gp:geopriv>
         </status>
       </tuple>
     </presence>

9.  GML Definitions

   Formal GML definitions for a coordinate reference system are provided
   in the PIDF-LO.  However, these definitions rely on the definitions
   in this document, plus the formal GML definitions included in the
   schema (Section 10).

   This section provides references to definitions of the various code
   points used in the formal definitions.

9.1.  Units of Measure

   This document uses the same restricted set of units of measure as
   defined in [RFC5491], with additions for the local CRS.

   The units for meters (urn:ogc:def:uom:EPSG::9001), degrees
   (urn:ogc:def:uom:EPSG::9102) and radians (urn:ogc:def:uom:EPSG::9101)
   are used where applicable.  Meters are used for all distance
   measures.  Degrees or radians are used for all angular measures.

   A pixel is defined as a subjective length measure.  In this
   definition, a pixel does cannot be used directly with other forms of
   length measure.  The pixel measure is context-dependent and can be
   related to other length measures by different factors.  The scaling
   (Section 6.5) parameters establish how pixels relate to other
   measures for a particular image.

   Additional units of measure are defined for pixels
   (urn:ietf:params:xml:schema:geopriv:indoor#px) and pixels per meter
   (urn:ietf:params:xml:schema:geopriv:indoor#pxpm).  Formal definitions



Thomson & Winterbottom    Expires June 3, 2010                 [Page 21]


Internet-Draft               Indoor Location               November 2009


   of these units are included in an annotation to the XML schema.
   Pixel coordinates are used to describe a position in an image.
   Pixels per meter are used to establish a scale for conversion between
   meters and pixels.

9.2.  Code Space Definitions

   The GML definitions for the local coordinate system rely on
   identifiers that are defined in the "http://ietf.org/rfc/rfcXXXX.txt"
   (the URL of this document [[EDITOR NOTE: Please update this link at
   publication]]).  These identifiers are defined thus:

   x  The x-axis of the local coordinate system.

   y  The y-axis of the local coordinate system.

   z  The z-axis of the three-dimensional local coordinate system.

   east+o  East from the reference point, rotated clockwise (about the
      Up vector) by the orientation angle, see Appendix A and
      Section 7.3.

   north+o  North from the reference point, rotated clockwise (about the
      Up vector) by the orientation angle, see Appendix A and
      Section 7.3.

   up Up from the reference point, see Appendix A and Section 7.3.

   pixel  The name for the pixels unit of measure, see Section 9.1.

   px The abbreviated name for the pixels unit of measure.

   pixels per metre  The English name for the pixels per meter unit of
      measure, using the standard spelling, see Section 9.1.

   pxpm  The abbreviated name for the pixels per meter unit of measure.

   Documents created to represent local locations use a document-local
   code space, signified by the absence of the "codeSpace" attribute.

10.  XML Schema

   The XML schema for the indoor location elements also includes a
   definition of the 2-dimensional and 3-dimensional local coordinate
   systems and units of measure used in definitions of coordinate
   reference systems.





Thomson & Winterbottom    Expires June 3, 2010                 [Page 22]


Internet-Draft               Indoor Location               November 2009


      To identify the elements that are defined in this schema, a URI is
      used.  This document is not identified by a URL, instead it uses
      the URN that is registered for identification of the schema
      "urn:ietf:params:xml:schema:geopriv:indoor".


   <?xml version="1.0"?>
   <xs:schema
       xmlns:in="urn:ietf:params:xml:ns:geopriv:indoor"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:gml="http://www.opengis.net/gml"
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
       targetNamespace="urn:ietf:params:xml:ns:geopriv:indoor"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

     <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL
          'http://ietf.org/rfc/rfcXXXX.txt' with the URL of published
          document and remove this note.]] -->

     <xs:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:geopriv:indoor">
         Indoor Location for PIDF-LO

         <!-- These definitions use the code-space definition
              'http://ietf.org/rfc/rfcXXXX.txt' -->
         <gml:Dictionary gml:id="defs">
           <gml:description>
             A dictionary including a Cartesian Coordinate System and
             units of measure for a system of indoor location.
           </gml:description>
           <gml:name>Indoor Location</gml:name>

           <!-- urn:ietf:params:xml:schema:geopriv:indoor#cs3d -->
           <gml:dictionaryEntry>
             <gml:CartesianCS gml:id="cs3d">
               <gml:csName>3-D Cartesian CS</gml:csName>
               <gml:usesAxis>
                 <gml:CoordinateSystemAxis
                     gml:id="x3d" gml:uom="urn:ogc:def:uom:EPSG::9001">
                   <gml:name>X-Axis</gml:name>
                   <gml:axisAbbrev
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                       >x</gml:axisAbbrev>
                   <gml:axisDirection
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"



Thomson & Winterbottom    Expires June 3, 2010                 [Page 23]


Internet-Draft               Indoor Location               November 2009


                       >east+o</gml:axisDirection>
                 </gml:CoordinateSystemAxis>
               </gml:usesAxis>
               <gml:usesAxis>
                 <gml:CoordinateSystemAxis
                     gml:id="y3d" gml:uom="urn:ogc:def:uom:EPSG::9001">
                   <gml:name>Y-Axis</gml:name>
                   <gml:axisAbbrev
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                       >y</gml:axisAbbrev>
                   <gml:axisDirection
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                       >north+o</gml:axisDirection>
                 </gml:CoordinateSystemAxis>
               </gml:usesAxis>
               <gml:usesAxis>
                 <gml:CoordinateSystemAxis
                     gml:id="z3d" gml:uom="urn:ogc:def:uom:EPSG::9001">
                   <gml:name>Z-Axis</gml:name>
                   <gml:axisAbbrev
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                       >z</gml:axisAbbrev>
                   <gml:axisDirection
                       codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                       >up</gml:axisDirection>
                 </gml:CoordinateSystemAxis>
               </gml:usesAxis>
             </gml:CartesianCS>
           </gml:dictionaryEntry>

           <!-- urn:ietf:params:xml:schema:geopriv:indoor#cs2d -->
           <gml:dictionaryEntry>
             <gml:CartesianCS gml:id="cs2d">
               <gml:csName>2-D Cartesian CS</gml:csName>
               <gml:usesAxis xlink:href="#x3d"/>
               <gml:usesAxis xlink:href="#y3d"/>
             </gml:CartesianCS>
           </gml:dictionaryEntry>

           <!-- urn:ietf:params:xml:schema:geopriv:indoor#px -->
           <gml:dictionaryEntry>
             <gml:BaseUnit gml:id="px">
               <gml:description>
                 The pixel is the basic unit of measure used in images.
               </gml:description>
               <gml:name codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                         >pixel</gml:name>
               <gml:quantityType>image units</gml:quantityType>



Thomson & Winterbottom    Expires June 3, 2010                 [Page 24]


Internet-Draft               Indoor Location               November 2009


               <gml:catalogSymbol
                   codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                   >px</gml:catalogSymbol>
               <gml:unitsSystem
                   xlink:href="http://ietf.org/rfc/rfcXXXX.txt"/>
             </gml:BaseUnit>
           </gml:dictionaryEntry>

           <!-- urn:ietf:params:xml:schema:geopriv:indoor#pxpm -->
           <gml:dictionaryEntry>
             <gml:DerivedUnit gml:id="pxpm">
               <gml:description>
                 A mapping of pixels to a length in metres.
               </gml:description>
               <gml:name codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                         >pixels per metre</gml:name>
               <gml:name codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                         xml:lang="en-US">pixels per meter</gml:name>
               <gml:quantityType>
                 mapping of local length to physical length
               </gml:quantityType>
               <gml:catalogSymbol
                   codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
                   >pxpm</gml:catalogSymbol>
               <gml:derivationUnitTerm uom="#px" exponent="1"/>
               <gml:derivationUnitTerm uom="urn:ogc:def:uom:EPSG::9001"
                                       exponent="-1"/>
             </gml:DerivedUnit>
           </gml:dictionaryEntry>
         </gml:Dictionary>
       </xs:appinfo>

       <xs:documentation source="http://ietf.org/rfc/rfcXXXX.txt">
         This schema defines a location representation that allows for
         the trivial creation of a locally-defined coordinate reference
         system; specifically one that is based on a local map image.
       </xs:documentation>

     </xs:annotation>

     <xs:import namespace="http://www.opengis.net/gml"/>
     <xs:import namespace="http://www.w3.org/1999/xlink"/>
     <xs:import
         namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>

     <xs:element name="IndoorDatum" type="in:IndoorDatumType"
                 substitutionGroup="gml:EngineeringDatum"/>




Thomson & Winterbottom    Expires June 3, 2010                 [Page 25]


Internet-Draft               Indoor Location               November 2009


     <xs:complexType name="IndoorDatumType">
       <xs:complexContent>
         <xs:extension base="gml:EngineeringDatumType">
           <xs:sequence>
             <xs:element name="anchor"
                         type="in:locationType"/>
             <xs:element name="orientation"
                         type="gml:AngleType"/>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>

     <!-- geodetic location, civic address, or both -->
     <xs:group name="locationGroup">
       <xs:choice>
         <xs:sequence>
           <xs:element ref="gml:_Geometry"/>
           <xs:element ref="ca:civicAddress" minOccurs="0"/>
         </xs:sequence>
         <xs:element ref="ca:civicAddress"/>
       </xs:choice>
     </xs:group>

     <xs:complexType name="locationType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:group ref="in:locationGroup"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="localMap" type="in:localMapType"/>

     <xs:complexType name="localMapType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="image" type="in:imageType"/>
             <xs:element name="referenceLocation"
                         type="in:referenceLocationType"/>
             <xs:element name="offset"
                         type="gml:MeasureListType" minOccurs="0"/>
             <xs:element name="scale" type="gml:MeasureListType"/>
           </xs:sequence>



Thomson & Winterbottom    Expires June 3, 2010                 [Page 26]


Internet-Draft               Indoor Location               November 2009


         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="imageType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attributeGroup ref="xlink:simpleLink"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="referenceLocationType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:choice>
             <xs:group ref="in:locationGroup"/>
             <xs:element name="crsOrigin"  minOccurs="0"
                         type="gml:CoordinateReferenceSystemRefType"/>
           </xs:choice>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>
   </xs:schema>

11.  Security Considerations

   This document describes information that is intended for inclusion
   within a location object, specifically a PIDF-LO.  The security
   concerns relating to the use of a location object are described in
   [RFC4119].  Further security and privacy considerations are included
   in [I-D.ietf-geopriv-arch].  No further considerations are known to
   apply.

12.  IANA Considerations

   This section registers a URN for the identification of XML elements
   for describing a local CRS, plus the schema that defines those
   elements.

12.1.  URN Sub-Namespace Registration for
       'urn:ietf:params:xml:ns:geopriv:indoor'

   This section registers a new XML namespace,



Thomson & Winterbottom    Expires June 3, 2010                 [Page 27]


Internet-Draft               Indoor Location               November 2009


   "urn:ietf:params:xml:ns:geopriv:indoor", per the guidelines in
   [RFC3688].

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

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>GEOPRIV: Indoor location representation</title>
             </head>
             <body>
               <h1>Namespace for Indoor location representation</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:indoor</h2>
       [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
       with the RFC number for this specification.]
               <p>See RFCXXXX</p>
             </body>
           </html>
         END

12.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:geopriv:indoor

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).

   Schema:  The XML for this schema can be found in Section 10 of this
      document starting with "<xs:schema" and ending with
      "</xs:schema>".

13.  Acknowledgements

   Cullen Jennings provided valuable feedback on the use of maps with
   early versions of this document.

14.  References



Thomson & Winterbottom    Expires June 3, 2010                 [Page 28]


Internet-Draft               Indoor Location               November 2009


14.1.  Normative References

   [RFC2119]                          Bradner, S., "Key words for use in
                                      RFCs to Indicate Requirement
                                      Levels", BCP 14, RFC 2119,
                                      March 1997.

   [RFC4119]                          Peterson, J., "A Presence-based
                                      GEOPRIV Location Object Format",
                                      RFC 4119, December 2005.

   [RFC5139]                          Thomson, M. and J. Winterbottom,
                                      "Revised Civic Location Format for
                                      Presence Information Data Format
                                      Location Object (PIDF-LO)",
                                      RFC 5139, February 2008.

   [RFC5491]                          Winterbottom, J., Thomson, M., and
                                      H. Tschofenig, "GEOPRIV Presence
                                      Information Data Format Location
                                      Object (PIDF-LO) Usage
                                      Clarification, Considerations, and
                                      Recommendations", RFC 5491,
                                      March 2009.

   [OGC.GeoShape]                     Thomson, M. and C. Reed, "GML
                                      3.1.1 PIDF-LO Shape Application
                                      Schema for use by the Internet
                                      Engineering Task Force (IETF)",
                                      OGC Best Practice 06-142r1,
                                      Version: 1.0, April 2007.

   [W3C.REC-xlink-20010627]           DeRose, S., Orchard, D., and E.
                                      Maler, "XML Linking Language
                                      (XLink) Version 1.0", World Wide
                                      Web Consortium Recommendation REC-
                                      xlink-20010627, June 2001, <http:/
                                      /www.w3.org/TR/2001/
                                      REC-xlink-20010627>.

14.2.  Informative References

   [RFC3688]                          Mealling, M., "The IETF XML
                                      Registry", BCP 81, RFC 3688,
                                      January 2004.

   [RFC3986]                          Berners-Lee, T., Fielding, R., and
                                      L. Masinter, "Uniform Resource



Thomson & Winterbottom    Expires June 3, 2010                 [Page 29]


Internet-Draft               Indoor Location               November 2009


                                      Identifier (URI): Generic Syntax",
                                      STD 66, RFC 3986, January 2005.

   [OGC.GML-3.1.1]                    Cox, S., Daisey, P., Lake, R.,
                                      Portele, C., and A. Whiteside,
                                      "Geographic information -
                                      Geography Markup Language (GML)",
                                      OpenGIS 03-105r1, April 2004, <htt
                                      p://portal.opengeospatial.org/
                                      files/?artifact_id=4700>.

   [I-D.ietf-geopriv-arch]            Barnes, R., Lepinski, M., Cooper,
                                      A., Morris, J., Tschofenig, H.,
                                      and H. Schulzrinne, "An
                                      Architecture for Location and
                                      Location Privacy in Internet
                                      Applications",
                                      draft-ietf-geopriv-arch-01 (work
                                      in progress), October 2009.

   [I-D.thomson-geopriv-uncertainty]  Thomson, M. and J. Winterbottom,
                                      "Representation of Uncertainty and
                                      Confidence in PIDF-LO", draft-
                                      thomson-geopriv-uncertainty-03
                                      (work in progress), June 2009.

Appendix A.  Calculating WGS84 ECEF Up, North and East Vectors

   Unit vectors corresponding to Up, North and East from a given point
   are used for transformation of coordinates between WGS84 and the
   local CRS.  These vectors are provided in the Cartesian coordinate
   system used by WGS84: the Earth-Centered, Earth-Fixed (ECEF) variant
   of WGS84 (X, Y, Z).

   These vectors change depending on location, but depend only on
   latitude and longitude; the altitude of the point has no affect on
   the vectors.

   The following values are used (where sin(x) is the sine function of x
   and cos(x) the cosine function): coslat = cos(latitude); sinlat =
   sin(latitude); coslng = cos(longitude); sinlng = sin(longitude).










Thomson & Winterbottom    Expires June 3, 2010                 [Page 30]


Internet-Draft               Indoor Location               November 2009


   When calculating the orientation of Up, North and East vectors in
   Earth-Centered, Earth-Fixed (ECEF) coordinates, inverse flattening of
   the WGS84 ellipsoid is not considered.  These vectors are:

      East  = [ -sinlng          ; coslng           ; 0      ]
      North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
      Up    = [ coslat * coslng  ; coslat * sinlng  ; sinlat ]

   These are all orthogonal unit vectors, therefore the matrix they form
   is also orthogonal.

   The Up vector plus the ECEF coordinates of a point defines the plane
   of the horizontal at that point:

      (x - c[x]) * Up[x] + (y - c[y]) * Up[y] + (z - c[z]) * Up[z] = 0

Authors' Addresses

   Martin Thomson
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   EMail: martin.thomson@andrew.com


   James Winterbottom
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   EMail: james.winterbottom@andrew.com













Thomson & Winterbottom    Expires June 3, 2010                 [Page 31]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/