One document matched: draft-thomson-geopriv-indoor-location-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC5491 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml">
<!ENTITY RFC5139 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY I-D.thomson-geopriv-uncertainty PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml">
<!ENTITY I-D.ietf-geopriv-arch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-arch.xml">
<!ENTITY W3C.REC-xlink-20010627 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xlink-20010627.xml">
]>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="trust200902">
<front>
<title abbrev="Indoor Location">
Locations with Locally-Defined Coordinate Reference Systems for the Presence Information Data Format - Location Object (PIDF-LO)
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Indoor</keyword>
<keyword>CRS</keyword>
<keyword>Uncertainty</keyword>
<keyword>GML</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<!-- <t>Determining the location of a device indoors or under cover is problematic. Obscured visibility to the open sky means that satellite positioning mechanisms such as GPS and assisted-GPS cannot be used. Walls, ceilings and floors all reflect radio signals which increases multi-path, reduces signal strength and introduces other radio interference. In addition to this, the exact position of indoor transceivers, such as 802.11 wireless access points, is also generally unknown. Techniques exist for determining the location of a WiFi device to within a few 10's of centremetres, but these locations are relative to the position of the WiFi access point, and there is currently no canonical way to be represented these locations in a PIDF-LO <xref target="RFC4119"/>.
</t>
<t>Relative coordinates are useful when it comes to placing markers on maps or floor plans, as they provide localized information that a a range of application may take advantage of. However, they provide little benefit for general applications that require a canonical location representation in WGS-84 coordinates or civic form. None of the LCPs defined in the IETF provide a service indicator to the LIS describing what the location information is going to be used for, so the LIS must assume that the location may be used for emergency purposes. This requires the LIS to express location information in a form that complies with the rules laid out in <xref target="RFC5491"/>.
</t> -->
<t>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.
</t>
<t>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.
</t>
<t>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.
<list style="empty">
<t>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.
</t>
<t>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.
</t>
</list>
For these cases and others like them, avoiding conversion steps ensures that unnecessary errors are not introduced.
</t>
<section title="Solution">
<t>A means to describe a location in relation to a fixed reference is defined. These locations use the forms defined in <xref target="OGC.GeoShape"/>, using a custom coordinate reference system (CRS).
</t>
<t>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.
</t>
<t>Guidelines are further provided for constructing a <xref target="RFC4119">Presence Information Data Format - Location Object (PIDF-LO) document</xref> so that existing applications and consumers of location information are able to operate. These guidelines are based on those described in <xref target="RFC5491">RFC 5491</xref>.
</t>
</section>
<section title="Example Use Case">
<t>A shopper uses the information contained in a PIDF-LO to identify the location of a store in a mall. The <xref target="OGC.GeoShape">geodetic location information</xref> or <xref target="RFC5139">civic address information</xref> helps the shopper identify the location of the mall.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
<section anchor="conventions" title="Conventions used in this document">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Overview">
<t>A location in a user-defined CRS is included in a PIDF-LO document as shown in <xref target="overview"/>, which includes the high-level elements involved.
</t>
<figure anchor="overview" title="PIDF-LO Structure Overview"><artwork><![CDATA[
<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>
]]></artwork></figure>
<t>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, <xref target="transform">transformation</xref> might be used to construct one or other location element.
</t>
<t>The first <spanx style="verb">tuple</spanx> (or <spanx style="verb">device</spanx> or <spanx style="verb">person</spanx>) contains <xref target="OGC.GeoShape">geodetic information</xref>. This first tuple uses a WGS84 CRS, so that the information is usable outside of the local context.
<list style="empty"><t>Aside from being required by <xref target="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.</t></list>
</t>
<t>A second <spanx style="verb">tuple</spanx> includes location information using a <xref target="OGC.GML-3.1.1">Geography Markup Language (GML)</xref> 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 included in the tuple with the shape.
</t>
<t>The CRS is defined only within the scope of the PIDF-LO. A URI fragment identifier is used to identify the CRS <spanx style="verb">srsName</spanx> parameters that reference the CRS.
</t>
<t>A reference to a GML dictionary containing the CRS MAY be used in place of the fragment identifier used in this document. An <spanx style="verb">http:</spanx> or <spanx style="verb">https:</spanx> 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.
</t>
<t>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.
</t>
</section>
<section title="Generating Local Location Information">
<t>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 <xref target="OGC.GeoShape"/> can be used with an <spanx style="verb">srsName</spanx> attribute that references the newly defined CRS, rather than WGS84.</t>
<figure>
<preamble>The locally-defined shapes only differ from those in <xref target="OGC.GeoShape"/> by the CRS identifier used:
</preamble>
<artwork><![CDATA[
<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>
]]></artwork></figure>
<t>A GML <spanx style="verb">EngineeringCRS</spanx> 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.
</t>
<t>The <spanx style="verb">gml:id</spanx> attribute of <spanx style="verb">EngineeringCRS</spanx> contains any valid XML name. The <spanx style="verb">srsName</spanx> includes a <xref target="RFC3986">URI fragment</xref> that refers to this identifier; this value is used in the <spanx style="verb">srsName</spanx> in place of a WGS84 CRS URI. No <spanx style="verb">codeSpace</spanx> attribute is included.
</t>
<figure><artwork><![CDATA[
<gml:EngineeringCRS gml:id="indoorCRS">
<gml:srsName>#indoorCRS</gml:srsName>
]]></artwork></figure>
<t>The CRS then needs a reference to the coordinate system defined in <xref target="cs">this document</xref>. This reference is provided using an <xref target="W3C.REC-xlink-20010627">XLink</xref> attribute:
</t>
<figure><artwork><![CDATA[
<gml:usesCS
xlink:href="urn:ietf:params:xml:schema:geopriv:indoor#cs2d"/>
]]></artwork></figure>
<t>An engineering datum is used to define how the coordinate system then relates to the local environment. This uses the <spanx style="verb">IndoorDatum</spanx> element defined in <xref target="indoorDatum">this document</xref>. This uses similar identification to the CRS definition:
</t>
<figure><artwork><![CDATA[
<indoor:IndoorDatum gml:id="officeDatum"
xmlns:indoor="urn:ietf:params:xml:ns:geopriv:indoor">
<gml:datumName>#officeDatum</gml:datumName>
...
</indoor:IndoorDatum>
]]></artwork></figure>
<t>An indoor datum requires a <xref target="anchor">reference point</xref> and an <xref target="orientation">orientation</xref> angle. The reference point is described using either a <xref target="OGC.GeoShape">geodetic shape</xref>, a <xref target="RFC5139">civic address</xref>, or both elements according to the rules in <xref target="RFC5491">RFC 5491</xref>. A complete example document is included in <xref target="example"/>.
</t>
<section title="Local Map Image">
<t>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.
</t>
<figure><artwork><![CDATA[
<indoor:localMap>
<indoor:image .../>
<indoor:referenceLocation .../>
<indoor:offset .../>
<indoor:scale .../>
</indoor:localMap>
]]></artwork></figure>
<t>The manner in which a map image can be related to the local coordinate system is described in <xref target="localMap"/>.
</t>
</section>
</section>
<section anchor="crs" title="Local Coordinate Reference System">
<t>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.
</t>
<t>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:
<list style="symbols">
<t>urn:ietf:params:xml:schema:geopriv:indoor#cs3d</t>
<t>urn:ietf:params:xml:schema:geopriv:indoor#cs2d</t>
</list>
</t>
<t>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.
</t>
<t><xref target="example"/> 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.
</t>
<section anchor="cs" title="Cartesian Coordinate System">
<t>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.
</t>
<t><xref target="schema"/> includes the definition of two Cartesian coordinate systems. The two-dimensional Cartesian coordinate system is identified by the URN <spanx style="verb">urn:ietf:params:xml:schema:geopriv:indoor#cs2d</spanx>. The three-dimensional Cartesian coordinate system is identified by the URN <spanx style="verb">urn:ietf:params:xml:schema:geopriv:indoor#cs3d</spanx>.
</t>
<t>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.
</t>
</section>
<section anchor="indoorDatum" title="Local or Indoor Datum">
<t>The image datum establishes a relationship between the coordinate system and a physical space.
</t>
<t>An extension of the GML <spanx style="verb">ImageDatum</spanx> type is used to define a datum precisely. This definition allows for transformation between the local CRS and WGS84.
</t>
<t><list style="hanging"><t hangText="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 <xref target="transform"/> ensures that this "reordering" does not introduce errors.
</t></list></t>
<section anchor="anchor" title="Anchor Location">
<t>This engineering datum identifies a point in space as the location of the origin. This can be objectively specified using WGS84 coordinates in a <xref target="OGC.GeoShape">geodetic shape</xref>; alternatively, it can be subjectively specified using a <xref target="RFC5139">civic address</xref>. Both forms of location data MAY be included.
</t>
<t>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.
</t>
<t>The <spanx style="verb">anchor</spanx> 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 <xref target="OGC.GeoShape"/>.
</t>
<t>A single reference point can derived from the provided location. The <xref target="I-D.thomson-geopriv-uncertainty">centroid of the geodetic shape</xref> 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.
</t>
<t>The means for determining a point from a civic address is not defined. The <spanx style="verb">LOC</spanx> field of the civic address can be used to provide a textual description of the reference point.
</t>
</section>
<section anchor="orientation" title="Orientation">
<t>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.
</t>
<t>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.
</t>
<t>The <spanx style="verb">orientation</spanx> 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 <xref target="whatsup"/>).
</t>
<t>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.</t>
<figure><artwork><![CDATA[
^ North
|
| _
+--._ /\ y-axis
| `. / (north+o)
| /
| /
| /
| /
| /
| /
|/ East
o-------------+--------->
`-._ |
`-._ ; orientation
`-._/
`-._
`_| x-axis
[ Up == z-axis ] (east+o)
]]></artwork></figure>
<t>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.
</t>
</section>
</section>
</section>
<section anchor="localMap" title="Local Map Presentation">
<t>A map image can be referred to using the <spanx style="verb">localMap</spanx> element. This allows for the locally defined location to be presented with additional context.
</t>
<t>Image information is placed in the <spanx style="verb">location-info</spanx> element after the shape information and CRS.
</t>
<section title="Image Coordinates">
<t>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.
</t>
<t>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 is in the opposite direction to the y-axis.
</t>
<figure anchor="imageaxes" title="Image Axes"><artwork><![CDATA[
(local coordinates)
^
|
y-axis
|
|
---- x-axis ---->
O------------------------------+
| ---- columns-axis ----> |
| | |
| | |
| rows-axis |
| | |
| v |
| (image coordinates) |
+------------------------------+
]]></artwork></figure>
<t>If a left-handed coordinate system is used in an image, the <xref target="scale">scale</xref> 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.
</t>
<t>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.
</t>
<figure title="Whole Integer Image Coordinates">
<preamble>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.
</preamble>
<artwork><![CDATA[
4 5 6 7
| | | |
12 --+--------+--------+--------+-
| | | |
| | | |
| | | |
13 --+--------+--------+--------+-
| | | |
| | [5,13] | |
| | | |
14 --+--------+--------+--------+-
| | | |
| | | |
| | | |
15 --+--------+--------+--------+-
| | | |
]]></artwork>
</figure>
</section>
<section anchor="image" title="Map Image">
<t>The optional <spanx style="verb">image</spanx> element includes an image, usually a map of the locality. This image might be used to display the associated location information to a user.
</t>
<t>Rather than include an image inline, this uses <xref target="W3C.REC-xlink-20010627">XLink</xref> to reference an image document. The <spanx style="verb">xlink:href</spanx> attribute contains a URL for the image. An <spanx style="verb">http:</spanx> or <spanx style="verb">https:</spanx> 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.
</t>
</section>
<section anchor="referenceLocation" title="Reference Location">
<t>The <spanx style="verb">referenceLocation</spanx> element describes the reference location used to place (and orient) the image in space. This can be specified in the same way that the <xref target="anchor">anchor location</xref> for the datum is specified using a geodetic shape or civic address.
</t>
<t>If a local CRS is defined in the same document, the reference point SHOULD refer the origin of the coordinate reference system, using the <spanx style="verb">crsOrigin</spanx> element. This references the anchor point used in the CRS definition, saving unnecessary duplication of this information.
</t>
<t>The rows-axis of the image is either along the negative y-axis of a 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 <xref target="whatsup"/> for details on how to determine North, East and Up vectors from an arbitrary point.
</t>
</section>
<section anchor="offset" title="Pixel Offset">
<t>The anchor point is matched to a point on the image, thus establishing a common point in both coordinate reference systems. The <spanx style="verb">offset</spanx> element includes the coordinates of the reference point in the image.
</t>
</section>
<section anchor="scale" title="Scaling">
<t>The <spanx style="verb">scale</spanx> 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.
</t>
<t>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.
</t>
<t>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).
</t>
<t>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 <xref target="imageaxes"/>.
</t>
<section title="Map Projections">
<t>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.
</t>
<t>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.
</t>
<t>This does not necessarily prevent the use of alternative map projections. For other map projections, the scaling factor changes as the distance from the reference point increases.
</t>
<t>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.
</t>
</section>
</section>
</section>
<section anchor="transform" title="Coordinate Transformation">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<section title="Conversion from WGS84 to Local CRS">
<t>To convert coordinates specified in WGS84 to coordinates specified in the local CRS use the following algorithm:
<list style="numbers">
<t>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.
</t>
<t>Convert the WGS84 (latitude, longitude, altitude) coordinates to WGS84 ECEF (X, Y, Z) values. One commonly used algorithm for this is documented in <xref target="I-D.thomson-geopriv-uncertainty"/>.
</t>
<t>If necessary, find the centroid of the reference location, specified in the <spanx style="verb">anchor</spanx> element, in WGS84 ECEF (X, Y, Z) coordinates. Algorithms for this are documented in <xref target="I-D.thomson-geopriv-uncertainty"/>.
</t>
<t>Subtract the ECEF reference location from the ECEF coordinates to get a relative position vector for the coordinates.
</t>
<t>Multiply the resulting relative position by the forward transformation matrix described in <xref target="matrix"/>. This gives distances in meters for each of the axes of the local coordinate system.
</t>
<t>If altitude was not originally provided, remove any vertical or z-axis component.
</t>
<t>If the reference location contains uncertainty, add this uncertainty to any uncertainty in the original location, see <xref target="extraunc"/>.
</t>
</list>
</t>
<figure><preamble>The results can be summarized as:</preamble>
<artwork><![CDATA[
C[local] = R * T[0] * (C[ecef] - R[ecef])
]]></artwork>
<postamble>Where all coordinates are expressed as column vectors and <spanx style="verb">*</spanx> is the matrix product.</postamble>
</figure>
<t>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.
</t>
<t>Coordinates can then be plotted on the map image by applying the following process:
<list style="numbers">
<t>Multiply each component of the vector by the scaling factor, specified in the <spanx style="verb">scale</spanx> element, to obtain values in pixels.
</t>
<t>Add the resulting value to the image offset, specified in the <spanx style="verb">offset</spanx> element, to obtain the coordinates in the image.
</t>
</list>
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.
</t>
<figure><preamble>The results can be summarized as:</preamble>
<artwork><![CDATA[
C[image] = offset + scale .* C[local]
]]></artwork>
<postamble>Where <spanx style="verb">.*</spanx> is the Hadamard or entrywise product.</postamble>
</figure>
</section>
<section title="Conversion from Local CRS to WGS">
<t>To convert coordinates specified in the local CRS to coordinates specified in WGS84 use the following algorithm:
<list style="numbers">
<t>If the coordinates do not include a vertical or z-axis component, set this value to zero.
</t>
<t>Multiply the resulting relative position by the reverse transformation matrix described in <xref target="matrix"/> to get a vector relative to the reference location.
</t>
<t>If necessary, find the centroid of the reference location, <spanx style="verb">origin</spanx>, in WGS84 ECEF (X, Y, Z) coordinates.
</t>
<t>Add the ECEF reference location to the ECEF coordinates.
</t>
<t>Convert the WGS84 ECEF (X, Y, Z) coordinates to WGS84 (latitude, longitude, altitude) values.
</t>
<t>If vertical or z-axis values were not provided, remove the altitude value.
</t>
<t>If the reference location contains uncertainty, add this uncertainty to any uncertainty in the original location.
</t>
</list>
</t>
<figure><preamble>The results can be summarized as:</preamble>
<artwork><![CDATA[
C[ecef] = transpose(R * T[0]) * (C[local]) + R[ecef]
]]></artwork>
<postamble>Where <spanx style="verb">transpose(...)</spanx> signifies the matrix transpose.</postamble>
</figure>
<t>If image coordinates are known, the local coordinates can be found by first following these steps:
<list style="numbers">
<t>Subtract the image offset from the coordinate values.
</t>
<t>Divide each component of the vector by the scaling factor.
</t>
</list>
</t>
<figure><preamble>The results can be summarized as:</preamble>
<artwork><![CDATA[
C[local] = (1/scale) .* (C[image] - offset)
]]></artwork>
<postamble>Where <spanx style="verb">1/scale</spanx> is 1 divided by the scaling factor.</postamble>
</figure>
</section>
<section anchor="matrix" title="Transformation Matrix">
<t>The transformation matrix used to convert coordinates between WGS84 and the local CRS uses the centroid of the origin location, contained in the <spanx style="verb">origin</spanx> element.
</t>
<t>The transformation matrix is formed from the North, East and Up vectors from the origin location. <xref target="whatsup"/> describes how to determine these vectors in WGS84 ECEF coordinates:
</t>
<figure><artwork><![CDATA[
East = [ -sinlng ; coslng ; 0 ]
North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
Up = [ coslat * coslng ; coslat * sinlng ; sinlat ]
]]></artwork></figure>
<t>This is used directly to form the following transformation matrix for the case where the orientation is zero:
</t>
<figure><artwork><![CDATA[
[ -sinlng ; coslng ; 0 ]
T[0] = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
[ coslat * coslng ; coslat * sinlng ; sinlat ]
]]></artwork></figure>
<t>The orientation of the map, included in the <spanx style="verb">orientation</spanx> element, affects the x-axis and y-axis parts of this matrix. The rotation matrix is a counter-clockwise rotation matrix, as follows:
</t>
<figure><artwork><![CDATA[
[ cos(orientation) ; -sin(orientation) ; 0 ]
R = [ sin(orientation) ; cos(orientation) ; 0 ]
[ 0 ; 0 ; 1 ]
]]></artwork></figure>
<t>Both <spanx style="verb">R</spanx> and <spanx style="verb">T[0]</spanx> 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>
<figure><artwork><![CDATA[
T = R * T[0]
]]></artwork></figure>
<t>When transforming from local coordinates to WGS84, the transformation matrix is transposed to find its inverse.
</t>
</section>
<section anchor="extraunc" title="Managing Uncertainty">
<t>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.
</t>
<t>An increase to uncertainty is applied when transforming both to and from WGS84. Repeated transformations can increase uncertainty indefinitely.
</t>
<t>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.
</t>
</section>
<section title="Angles of Orientation">
<t>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.
</t>
</section>
</section>
<section anchor="example" title="Example PIDF-LO">
<figure><preamble>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.</preamble>
<artwork><![CDATA[
<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>
<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"/>
<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>
]]></artwork></figure>
</section>
<section title="GML Definitions">
<t>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 <xref target="schema">the schema</xref>.
</t>
<t>This section provides references to definitions of the various code points used in the formal definitions.
</t>
<section anchor="uom" title="Units of Measure">
<t>This document uses the same restricted set of units of measure as defined in <xref target="RFC5491"/>, with additions for the local CRS.
</t>
<t>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.
</t>
<t>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 <xref target="scale">scaling</xref> parameters establish how pixels relate to other measures for a particular image.
</t>
<t>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 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.
</t>
</section>
<section anchor="codeSpace" title="Code Space Definitions">
<t>The GML definitions for the local coordinate system rely on identifiers that are defined in the <spanx style="verb">http://ietf.org/rfc/rfcXXXX.txt</spanx> (the URL of this document [[EDITOR NOTE: Please update this link at publication]]). These identifiers are defined thus:
<list style="hanging">
<t hangText="x">The x-axis of the local coordinate system.
</t>
<t hangText="y">The y-axis of the local coordinate system.
</t>
<t hangText="z">The z-axis of the three-dimensional local coordinate system.
</t>
<t hangText="east+o">East from the reference point, rotated clockwise (about the Up vector) by the orientation angle, see <xref target="whatsup"/> and <xref target="matrix"/>.
</t>
<t hangText="north+o">North from the reference point, rotated clockwise (about the Up vector) by the orientation angle, see <xref target="whatsup"/> and <xref target="matrix"/>.
</t>
<t hangText="up">Up from the reference point, see <xref target="whatsup"/> and <xref target="matrix"/>.
</t>
<t hangText="pixel">The name for the pixels unit of measure, see <xref target="uom"/>.
</t>
<t hangText="px">The abbreviated name for the pixels unit of measure.
</t>
<t hangText="pixels per metre">The English name for the pixels per meter unit of measure, using the standard spelling, see <xref target="uom"/>.
</t>
<t hangText="pxpm">The abbreviated name for the pixels per meter unit of measure.
</t>
</list>
</t>
<t>Documents created to represent local locations use a document-local code space, signified by the absence of the <spanx style="verb">codeSpace</spanx> attribute.
</t>
</section>
</section>
<section anchor="schema" title="XML Schema">
<t>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.
<list style="empty">
<t>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 <spanx style="verb">urn:ietf:params:xml:schema:geopriv:indoor</spanx>.</t>
</list>
</t>
<figure>
<artwork><![CDATA[
<?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"
>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>
<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"/>
<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>
</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>
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>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 <xref target="RFC4119"/>. Further security and privacy considerations are included in <xref target="I-D.ietf-geopriv-arch"/>. No further considerations are known to apply.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section registers a URN for the identification of XML elements for describing a local CRS, plus the schema that defines those elements.</t>
<section anchor="iana-ns" title="URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:geopriv:indoor'">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:indoor</spanx>, per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:indoor</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t>XML: <figure>
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
</list></t>
</section>
<section anchor="iana-schema" title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"></xref>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geopriv:indoor</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
</t>
<t hangText="Schema:">
The XML for this schema can be found in <xref target="schema"></xref> of this document starting with <spanx style="verb"><xs:schema</spanx> and ending with <spanx style="verb"></xs:schema></spanx>.
</t>
</list></t>
</section>
</section>
<section title="Acknowledgements">
<t>Cullen Jennings provided valuable feedback on the use of maps with early versions of this document.
</t>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4119;
&RFC5139;
&RFC5491;
<reference anchor="OGC.GeoShape">
<front>
<title abbrev="GeoShape">GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
</author>
<author initials="C." surname="Reed" fullname="Carl Reed, PhD.">
<organization>Open Geospatial Consortium Inc.</organization>
</author>
<date month="April" day="10" year="2007"/>
</front>
<seriesInfo name="OGC Best Practice"
value="06-142r1, Version: 1.0"/>
</reference>
&W3C.REC-xlink-20010627;
</references>
<references title="Informative References">
&RFC3688;
&RFC3986;
<reference anchor="OGC.GML-3.1.1" target="http://portal.opengeospatial.org/files/?artifact_id=4700">
<front>
<title>Geographic information - Geography Markup Language (GML)</title>
<author initials="S" surname="Cox" fullname="Simon Cox">
<organization />
</author>
<author initials="P" surname="Daisey" fullname="Paul Daisey">
<organization />
</author>
<author initials="R" surname="Lake" fullname="Ron Lake">
<organization />
</author>
<author initials="C" surname="Portele" fullname="Clemens Portele">
<organization />
</author>
<author initials="A" surname="Whiteside" fullname="Arliss Whiteside">
<organization />
</author>
<date month="April" day="19" year="2004" />
<abstract>
<t>Geography Markup Language is an XML grammar written in XML Schema for the modelling, transport, and storage of geographic information.
</t>
</abstract>
</front>
<seriesInfo name="OpenGIS" value="03-105r1" />
</reference>
&I-D.ietf-geopriv-arch;
&I-D.thomson-geopriv-uncertainty;
</references>
<section anchor="whatsup" title="Calculating WGS84 ECEF Up, North and East Vectors">
<t>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).
</t>
<t>These vectors change depending on location, but depend only on latitude and longitude; the altitude of the point has no affect on the vectors.
</t>
<t>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).
</t>
<figure>
<preamble>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:</preamble>
<artwork><![CDATA[
East = [ -sinlng ; coslng ; 0 ]
North = [ -sinlat * coslng ; -sinlat * sinlng ; coslat ]
Up = [ coslat * coslng ; coslat * sinlng ; sinlat ]
]]></artwork>
<postamble>These are all orthogonal unit vectors, therefore the matrix they form is also orthogonal.</postamble>
</figure>
<figure>
<preamble>The Up vector plus the ECEF coordinates of a point defines the plane of the horizontal at that point:</preamble>
<artwork><![CDATA[
(x - c[x]) * Up[x] + (y - c[y]) * Up[y] + (z - c[z]) * Up[z] = 0
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:04 |