GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Corporation
Expires: April 11, 2010 October 8, 2009
Locations with Locally-Defined Coordinate Reference Systems for the
Presence Information Data Format - Location Object (PIDF-LO)
draft-thomson-geopriv-indoor-location-00
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 April 11, 2010.
Copyright Notice
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
A method is described for constructing a Presence Information Data
Format - Location Object (PIDF-LO) document that contains location
Thomson & Winterbottom Expires April 11, 2010 [Page 1]
Internet-Draft Indoor Location October 2009
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.
Thomson & Winterbottom Expires April 11, 2010 [Page 2]
Internet-Draft Indoor Location October 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
5. Image-based Coordinate Reference System . . . . . . . . . . . 8
5.1. Image-based Coordinate System . . . . . . . . . . . . . . 8
5.2. Local or Indoor Datum . . . . . . . . . . . . . . . . . . 10
5.2.1. Origin Point . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Origin Address . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Pixel Offset . . . . . . . . . . . . . . . . . . . . . 10
5.2.4. Orientation . . . . . . . . . . . . . . . . . . . . . 10
5.2.5. Scaling . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.6. Map Image . . . . . . . . . . . . . . . . . . . . . . 12
5.2.7. Pixel-Coordinate Relation . . . . . . . . . . . . . . 12
6. Considerations for Shape Representation . . . . . . . . . . . 13
6.1. Z-Axis Inversion . . . . . . . . . . . . . . . . . . . . . 13
6.2. Distances . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Angles of Orientation . . . . . . . . . . . . . . . . . . 13
7. Coordinate Transformation . . . . . . . . . . . . . . . . . . 13
7.1. Conversion from WGS84 to Local CRS . . . . . . . . . . . . 14
7.2. Conversion from Local CRS to WGS . . . . . . . . . . . . . 15
7.3. Transformation Matrix . . . . . . . . . . . . . . . . . . 16
7.4. Polygons and Prisms . . . . . . . . . . . . . . . . . . . 16
7.5. Angles of Orientation . . . . . . . . . . . . . . . . . . 17
7.6. Managing Uncertainty . . . . . . . . . . . . . . . . . . . 17
8. Example PIDF-LO . . . . . . . . . . . . . . . . . . . . . . . 17
9. GML Definitions . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Units of Measure . . . . . . . . . . . . . . . . . . . . . 19
9.2. Code Space Definitions . . . . . . . . . . . . . . . . . . 20
10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:indoor' . . . . . . . . . 25
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Calculating WGS84 ECEF Up, North and East Vectors . . 28
Thomson & Winterbottom Expires April 11, 2010 [Page 3]
Internet-Draft Indoor Location October 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 trivial 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 April 11, 2010 [Page 4]
Internet-Draft Indoor Location October 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 April 11, 2010 [Page 5]
Internet-Draft Indoor Location October 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
<ImageCRS ...> * image CRS
<srsName>#indoorCRS</srsName>
<usesCartesianCS .../> * image coordinates
<usesImageDatum>
<IndoorDatum .../> * indoor datum
</usesImageDatum>
</ImageCRS>
</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 operations,
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
included in the tuple with the shape.
Thomson & Winterbottom Expires April 11, 2010 [Page 6]
Internet-Draft Indoor Location October 2009
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.
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.
A GML "ImageCRS" element is used to define an image CRS. An image
CRS is formed of an identifier and name, a coordinate system and a
datum.
The "gml:id" attribute of "ImageCRS" contains any valid XML name.
The "srsName" includes a URI fragment [RFC3986] that refers to this
identifier, this is the value that is used in the "srsName" in place
of a WGS84 CRS URI. The local "codeSpace" of "#" is included to
indicate that definition is only valid within the scope of this
document:
<gml:ImageCRS gml:id="officeCRS">
<gml:srsName codeSpace="#">#officeCRS</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:usesCartesianCS
xlink:href="urn:ietf:params:xml:schema:geopriv:indoor#i2d"/>
An image 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:
Thomson & Winterbottom Expires April 11, 2010 [Page 7]
Internet-Draft Indoor Location October 2009
<indoor:IndoorDatum gml:id="officeDatum"
xmlns:indoor="urn:ietf:params:xml:ns:geopriv:indoor">
<gml:datumName codeSpace="#">#officeDatum</gml:datumName>
...
</indoor:IndoorDatum>
An indoor datum requires a reference point (Section 5.2.1), an
orientation (Section 5.2.4) angle, and a scaling factor
(Section 5.2.5). An indoor datum optionally includes a civic address
(Section 5.2.2), a pixel offset (Section 5.2.3) and a link to an
image (Section 5.2.6). A complete example document is included in
Section 8.
If a map image is used as a reference, then pixel coordinates from an
image can then be used directly.
5. Image-based 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.
Note: This encoding specifically uses an image-based CRS, and
provides a means to relate the information to a specific image.
However, this CRS can be used in any local context, with or
without an image, to describe the location in terms that are more
useful within that context.
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:
o urn:ietf:params:xml:schema:geopriv:indoor#i3d
o urn:ietf:params:xml:schema:geopriv:indoor#i2d
The datum that establishes the origin for the coordinate system is
defined during construction of the PIDF-LO. The datum is specific to
a particular location.
Section 8 shows an example definition of an coordinate reference
system that include the definition of a location-specific image datum
that corresponds to a floor plan.
5.1. Image-based Coordinate System
A custom coordinate reference system (CRS) is defined for use in
representing indoor locations. This allows positions to be expressed
Thomson & Winterbottom Expires April 11, 2010 [Page 8]
Internet-Draft Indoor Location October 2009
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#i2d". The three-
dimensional Cartesian coordinate system is identified by the URN
"urn:ietf:params:xml:schema:geopriv:indoor#i3d".
The two-dimensional coordinate system uses x- and y-axes to represent
coordinates in relation to an image.
Location in relation to an image generally uses a coordinate system
with an origin in the upper right. Values on the x-axis increase to
the right and values on the y-axis increase towards the bottom. This
coordinate system - inherited from the path that the beam in a
Cathode-ray tube follows - inverts the y-axis from mathematical
convention.
----- x-axis ---->
O---------------------------+
| | |
| | |
y-axis | |
| | |
v | |
| |
+---------------------------+
A consequence of inverting the y-axis is that the z-axis is also
inverted.
Any value containing altitude that is expressed in this coordinate
system has the z-axis (altitude) inverted. A positive z-axis value
corresponds to a point below the reference plane. A negative z-axis
value corresponds to a point above the reference plane. That is, if
the image is a map as viewed from above, altitude increases as values
on the z-axis decrease.
An alternative would be to use different mathematical conventions
within this coordinate system, which is inconvenient.
These two coordinate systems both use a unit of pixels (Section 9.1)
to represent coordinates.
Thomson & Winterbottom Expires April 11, 2010 [Page 9]
Internet-Draft Indoor Location October 2009
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.
5.2.1. Origin Point
This image datum identifies a point in space, using a geodetic shape.
The "origin" element allows for the inclusion of any form of GML
geometry, but this MUST use one of the shapes from [OGC.GeoShape].
A single reference point is derived from the provided shape. The
centroid of the geodetic shape [I-D.thomson-geopriv-uncertainty] is
used if the origin is included with uncertainty. This reference
point is used to anchor the local datum, as well as establishing the
plane of the horizontal.
5.2.2. Origin Address
A geodetic reference point provides a basis for unambiguous
transformation between locations in the locally-defined CRS and
WGS84. For human consumption, civic addresses [RFC5139] are often
more usable.
A "civicAddress" element MAY be included in the "address" element to
provide a user with more information about the reference point. The
"LOC" field of the civic address can be used to provide a textual
description of the reference point used.
5.2.3. Pixel Offset
The origin point is related to a point on the image, thus
establishing a common point in both coordinate reference systems.
Unless otherwise specified, the top-left corner pixel (0,0) of the
image is used. The optional "offset" element includes the
coordinates of the reference point in the local CRS - that is, the
position of the reference point on the image.
5.2.4. Orientation
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. Thus, the orientation of a local datum is often rotated.
Thomson & Winterbottom Expires April 11, 2010 [Page 10]
Internet-Draft Indoor Location October 2009
The "orientation" element describes the angle between North at the
reference location (see Appendix A) and the negative y-axis in the
local datum. Increasing values rotate the image in a clockwise
direction as viewed from above.
5.2.5. Scaling
The "scale" element includes a value in pixels per meter that
describes how coordinates in the local datum, specified in pixels,
are translated to coordinates in meters.
A scaling factor must be provided for each axis in the coordinate
system. For a two-dimensional coordinate system, two values can be
included to allow for different scaling along the x- and y-axis
independently. For a three-dimensional coordinate system, three
values can be specified for the x-, y- and z-axes.
Alternatively, a single scaling value can be used to apply the same
scaling factor to all coordinate components (x- and y-axes, and
optionally the z-axis).
5.2.5.1. Implications of Scaling
A means is provided for the image-based coordinate system to have
different scaling factors along each axis. While this provides for
greater flexibility in accomodating images with varying aspect
ratios, it also causes skewing of angles and distances.
A consequence of this is that the unit of measure defined in this
document - pixels - is context dependent. Values in pixels can only
be reliably applied along the axis upon which they were designed.
Therefore, distances are better expressed using meters.
Distances cannot be calculated using the image-based coordinates
directly unless the same scaling value is used on all axes.
Individual components MUST first be converted to meters before any
calculations are performed. This ensures that any resulting
distances derived from these coordinates are correct.
For instance, given scaling of (4, 5), the distance between (4,
12) and (9, 24) cannot be said to be 13 pixels because the values
along the x-axis are a different unit to the values along the
y-axis. To calculate a distance, the two points are first
converted to coordinates in meters: (1, 2.4) and (1.25, 4.8).
Then the distance can be calculated as 2.413 meters.
Similarly, the azimuth of a vector cannot be directly determined
using the components of the vector as express in pixels. Conversion
Thomson & Winterbottom Expires April 11, 2010 [Page 11]
Internet-Draft Indoor Location October 2009
of each component to meters is required.
5.2.5.2. Other Applications of Scaling
Local policy can dictate that coordinates are expressed in meters (or
some other commonly used local distance measure). Because the pixel
measure is context-dependent, its definition can be aligned with any
measure type for local applications. In this way, the CRS definition
is applied as an engineering CRS [OGC.GML-3.1.1], without relying on
a strict definition.
In this case, scaling is used so that coordinates in pixels
correspond to some other measure. In this case, a single scaling
value ensures that the local measure is consistent across axes. An
image reference SHOULD NOT be included to avoid any use of
coordinates in relation to the image.
Distance measures are still provided in meters to ensure that clients
outside the local context can make use of the information.
5.2.6. 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
information.
5.2.7. Pixel-Coordinate Relation
GML defines the "pixelInCell" element for image datums, allowing for
fact that pixels have area. Whole integer values for coordinates can
be anchored to any point in the rectangular area defined by a single
pixel. The "pixelInCell" value determines where in an individual
pixel coordinates with whole integer values lie.
This document uses a single value for "pixelInCell". The value
"cellCenter", which is defined to be in the code space
"urn:ogc:def:pixelInCell:OGC:1.0:" (see [OGC.ImageCRS]) indicates
that whole integer values for coordinates are found in the precise
center of a pixel.
Thomson & Winterbottom Expires April 11, 2010 [Page 12]
Internet-Draft Indoor Location October 2009
6. Considerations for Shape Representation
The set of shapes defined in [OGC.GeoShape] can be used with the
indoor CRS defined using these guidelines.
6.1. Z-Axis Inversion
The consequence of this inversion is that the upward normal of a
geodetic shape [OGC.GeoShape] needs to be inverted to ensure that the
resulting volume matches expectations (that is, upward normals are
still required to point in a direction that matches expectations of
"up").
In practice, this does not require any changes to shape definitions.
A Polygon is still specified in an anti-clockwise direction as viewed
from above. However, the upward normal vector will have a negative
inner product with the z-axis of the modified space.
6.2. Distances
Distances, such as radii or the semi-major and semi-minor axes of an
ellipse, are represented in meters in the local system. The pixels
unit cannot be used for distance measures.
6.3. Angles of Orientation
Angles of orientation in the image datum are measured from the
negative y-axis (the line pointing to the top of an image),
consistent with the way that North is represented in images. Thus,
an angle of 0 degrees indicates a direction along the negative
y-axis; an angle of 90 degrees indicates a direction along the
positive x-axis.
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. To that
end, a means is provided to provide information necessary to
transform shapes 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
Thomson & Winterbottom Expires April 11, 2010 [Page 13]
Internet-Draft Indoor Location October 2009
system.
The WGS84 origin 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.
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 "origin" 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.
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 image coordinate
system.
6. Multiply each component of the vector by the scaling factor,
specified in the "scale" element, to obtain values in pixels.
7. Add the resulting value to the image offset, specified in the
"offset" element, to obtain the coordinates in the local CRS.
8. If altitude was not originally provided, remove any vertical or
z-axis component.
9. If the reference location contains uncertainty, add this
uncertainty to any uncertainty in the original location, see
Section 7.6.
Thomson & Winterbottom Expires April 11, 2010 [Page 14]
Internet-Draft Indoor Location October 2009
The results can be summarized as:
C[local] = offset + scale .* R * T[0] * (C[ecef] - R[ecef])
Where all coordinates are expressed as column vectors, "*" is the
matrix product and ".*" is the Hadamard or entrywise product.
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. Subtract the image offset from the coordinate values.
3. Divide each component of the vector by the scaling factor.
4. Multiply the resulting relative position by the reverse
transformation matrix described in Section 7.3 to get a vector
relative to the reference location.
5. If necessary, find the centroid of the reference location,
"origin", in WGS84 ECEF (X, Y, Z) coordinates.
6. Add the ECEF reference location to the ECEF coordinates.
7. Convert the WGS84 ECEF (X, Y, Z) coordinates to WGS84 (latitude,
longitude, altitude) values.
8. If vertical or z-axis values were not provided, remove the
altitude value.
9. If the reference location contains uncertainty, add this
uncertainty to any uncertainty in the original location.
The results can be summarized as:
C[ecef] = (1/scale) .* transpose(R * T[0]) * (C[local] - offset)
+ R[ecef]
Where "transpose(...)" signifies the matrix transpose and "1/scale"
is 1 divided by the scaling factor.
Thomson & Winterbottom Expires April 11, 2010 [Page 15]
Internet-Draft Indoor Location October 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 ]
Without rotation, the x-axis of the coordinate system corresponds to
East, the y-axis corresponds to the negative North vector and the
z-axis corresponds to the negative Up vector. This gives 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. Polygons and Prisms
Each point in a Polygon or Prism is transformed independently using
the same process. The transformation process causes the direction of
the points to be reversed. Therefore, no additional steps are
required to ensure the correct orientation of the upward normal a
Thomson & Winterbottom Expires April 11, 2010 [Page 16]
Internet-Draft Indoor Location October 2009
Polygon or Prism.
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.
7.6. 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
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.
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.
All optional elements are included in 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: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">3
Thomson & Winterbottom Expires April 11, 2010 [Page 17]
Internet-Draft Indoor Location October 2009
</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:indoor:dict#pixels">30
</gs:radius>
</gs:Circle>
<gml:ImageCRS gml:id="officeCRS">
<gml:srsName codeSpace="#">#officeCRS</gml:srsName>
<gml:usesCartesianCS
xlink:href="urn:ietf:params:xml:schema:geopriv:indoor#i2d"/>
<gml:usesImageDatum>
<indoor:IndoorDatum gml:id="officeDatum"
xmlns:indoor="urn:ietf:params:xml:ns:geopriv:indoor">
<gml:datumName
codeSpace="#">#officeDatum</gml:datumName>
<gml:pixelInCell
codeSpace="urn:ogc:def:pixelInCell:OGC:1.0:"
>cellCenter</gml:pixelInCell>
<indoor:origin>
<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>
</indoor:origin>
<indoor:address>
<ca:civicAddress xml:lang="en"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<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>
Thomson & Winterbottom Expires April 11, 2010 [Page 18]
Internet-Draft Indoor Location October 2009
<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:address>
<indoor:offset
uom="urn:ietf:params:xml:schema:geopriv:indoor#px">374 184
</indoor:offset>
<indoor:orientation
uom="urn:ogc:def:uom:EPSG::9102">8.4
</indoor:orientation>
<indoor:scale
uom="urn:ietf:params:xml:schema:geopriv:indoor#pxpm">20
</indoor:scale>
<indoor:image
xlink:href="http://example/floorplan.png"/>
</indoor:IndoorDatum>
</gml:usesImageDatum>
</gml:ImageCRS>
</gp:location-info>
<gp:usage-rules/>
<gp:method>RSSI-RTT</gp:method>
</gp:geopriv>
</status>
</tuple>
</presence>
9. GML Definitions
Formal GML definitions 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.
Thomson & Winterbottom Expires April 11, 2010 [Page 19]
Internet-Draft Indoor Location October 2009
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.
Pixels are used to describe coordinates in the local datum. Pixels
per meter are used to establish a scale for conversion between meters
(used in WGS84) and pixels (used in the local CRS).
A pixel is nominally a length measure in this definition. However,
this definition does not relate the measure to any other form of
length measure. The pixel measure is context-dependent and can be
related to other length measures by different factors. The scaling
(Section 5.2.5) parameters of the datum establish how pixels relate
to other measures, such as meters.
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:
ix The x-axis of the image-based coordinate system.
iy The y-axis of the image-based coordinate system.
iz The z-axis of the image-based 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.
south+o South from the reference point, rotated clockwise (about the
Up vector) by the orientation angle, see Appendix A and
Section 7.3.
down Down 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.
Thomson & Winterbottom Expires April 11, 2010 [Page 20]
Internet-Draft Indoor Location October 2009
pixels per meter The US English name for the pixels per meter unit
of measure.
pxpm The abbreviated name for the pixels per meter unit of measure.
Documents created by this document will use a document-local code
space, signified by use of the URI fragment: "#".
10. XML Schema
The XML schema for the indoor location elements also includes a
definition of the 2-dimensional and 3-dimensional image-based
coordinate systems and units of measure used in definitions of
coordinate reference systems.
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>
Thomson & Winterbottom Expires April 11, 2010 [Page 21]
Internet-Draft Indoor Location October 2009
<gml:name>Indoor Location</gml:name>
<!-- urn:ietf:params:xml:schema:geopriv:indoor#i3d -->
<gml:dictionaryEntry>
<gml:CartesianCS gml:id="i3d">
<gml:usesAxis>
<gml:CoordinateSystemAxis uom="#px">
<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 uom="#px">
<gml:axisAbbrev
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>y</gml:axisAbbrev>
<gml:axisDirection
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>south-o</gml:axisDirection>
</gml:CoordinateSystemAxis>
</gml:usesAxis>
<gml:usesAxis>
<gml:CoordinateSystemAxis uom="#px">
<gml:axisAbbrev
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>z</gml:axisAbbrev>
<gml:axisDirection
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>down</gml:axisDirection>
</gml:CoordinateSystemAxis>
</gml:usesAxis>
</gml:CartesianCS>
</gml:dictionaryEntry>
<!-- urn:ietf:params:xml:schema:geopriv:indoor#i2d -->
<gml:dictionaryEntry>
<gml:CartesianCS gml:id="i2d">
<gml:usesAxis>
<gml:CoordinateSystemAxis uom="#px">
<gml:axisAbbrev
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>x</gml:axisAbbrev>
<gml:axisDirection
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
Thomson & Winterbottom Expires April 11, 2010 [Page 22]
Internet-Draft Indoor Location October 2009
>east+o</gml:axisDirection>
</gml:CoordinateSystemAxis>
</gml:usesAxis>
<gml:usesAxis>
<gml:CoordinateSystemAxis uom="#px">
<gml:axisAbbrev
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>y</gml:axisAbbrev>
<gml:axisDirection
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
>south-o</gml:axisDirection>
</gml:CoordinateSystemAxis>
</gml:usesAxis>
</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 quanta</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#ppm -->
<gml:dictionaryEntry>
<gml:DerivedUnit gml:id="pxpm">
<gml:description>
A mapping of length in 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 pixels to length
</gml:quantityType>
<gml:catalogSymbol
codeSpace="http://ietf.org/rfc/rfcXXXX.txt"
Thomson & Winterbottom Expires April 11, 2010 [Page 23]
Internet-Draft Indoor Location October 2009
>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:ImageDatum"/>
<xs:complexType name="IndoorDatumType">
<xs:complexContent>
<xs:extension base="gml:ImageDatumType">
<xs:sequence>
<xs:element name="origin"
type="gml:GeometryPropertyType"/>
<xs:element name="address"
type="in:addressType" minOccurs="0"/>
<xs:element name="offset"
type="gml:MeasureListType" minOccurs="0"/>
<xs:element name="orientation"
type="gml:AngleType"/>
<xs:sequence minOccurs="0">
<xs:element name="scale"
type="gml:MeasureListType"/>
<xs:element name="image"
type="in:linkType" minOccurs="0"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
Thomson & Winterbottom Expires April 11, 2010 [Page 24]
Internet-Draft Indoor Location October 2009
</xs:complexContent>
</xs:complexType>
<xs:complexType name="linkType">
<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="addressType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="ca:civicAddress"/>
</xs:sequence>
</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,
"urn:ietf:params:xml:ns:geopriv:indoor", per the guidelines in
[RFC3688].
Thomson & Winterbottom Expires April 11, 2010 [Page 25]
Internet-Draft Indoor Location October 2009
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
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
Thomson & Winterbottom Expires April 11, 2010 [Page 26]
Internet-Draft Indoor Location October 2009
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., Maler, E., and D.
Orchard, "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>.
[OGC.ImageCRS] Whiteside, A., "Recommended XML/
GML 3.1.1 encoding of image CRS
definitions", OGC Recommendation
Paper 05-027r1, April 2005, <http:
//portal.opengeospatial.org/files/
?artifact_id=10048>.
14.2. Informative References
[RFC3688] Mealling, M., "The IETF XML
Registry", BCP 81, RFC 3688,
January 2004.
Thomson & Winterbottom Expires April 11, 2010 [Page 27]
Internet-Draft Indoor Location October 2009
[RFC3986] Berners-Lee, T., Fielding, R., and
L. Masinter, "Uniform Resource
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-00 (work
in progress), July 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 April 11, 2010 [Page 28]
Internet-Draft Indoor Location October 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 April 11, 2010 [Page 29]