GEOPRIV M. Thomson
Internet-Draft Andrew
Expires: June 16, 2007 December 13, 2006
Geodetic Shapes for the Representation of Uncertainty in PIDF-LO
draft-thomson-geopriv-geo-shape-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Thomson Expires June 16, 2007 [Page 1]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Abstract
This document defines a set of shapes for the representation of
uncertainty for PIDF-LO geodetic location information. This includes
a GML profile and a schema that defines additional geometries.
Further recommendations are made to restrict the use of geographic
Coordinate Reference Systems (CRS) and units of measure restrictions
that improve interoperability.
Thomson Expires June 16, 2007 [Page 2]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. About Location Information . . . . . . . . . . . . . . . . 6
3.1.1. Coordinate Reference Systems . . . . . . . . . . . . . 6
3.1.2. Uncertainty . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Confidence . . . . . . . . . . . . . . . . . . . . . . 7
4. General Information . . . . . . . . . . . . . . . . . . . . . 9
4.1. GML Version and Profile . . . . . . . . . . . . . . . . . 9
4.2. Coordinate Reference Systems . . . . . . . . . . . . . . . 9
4.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 9
4.4. Approximations . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Lines and Distances . . . . . . . . . . . . . . . . . 10
4.4.2. Planar Approximation . . . . . . . . . . . . . . . . . 11
5. Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Polygon Upward Normal . . . . . . . . . . . . . . . . 14
5.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Application Schema . . . . . . . . . . . . . . . . . . . . . . 21
7. GML Profile Schema . . . . . . . . . . . . . . . . . . . . . . 24
7.1. geometryPrimitives.xsd . . . . . . . . . . . . . . . . . . 24
7.2. geometryBasic2d.xsd . . . . . . . . . . . . . . . . . . . 28
7.3. geometryBasic0d1d.xsd . . . . . . . . . . . . . . . . . . 30
7.4. measures.xsd . . . . . . . . . . . . . . . . . . . . . . . 34
7.5. gmlBase.xsd . . . . . . . . . . . . . . . . . . . . . . . 35
7.6. basicTypes.xsd . . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:geoShape . . . . . . 38
9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Calculating the Upward Normal of a Polygon . . . . . 43
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46
Thomson Expires June 16, 2007 [Page 3]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
1. Introduction
This document defines how geodetic location information is specified
in a PIDF-LO [RFC4119] document.
PIDF-LO [RFC4119] specifies that the feature schema from version 3.0
of GML be supported by all implementations. However, this is not
practical for a number of reasons.
The feature schema, and the schema that it relies upon, includes a
sizable proportion of the GML data types. This includes parts of the
geometry and temporal schema that are rarely applicable in the domain
where PIDF-LO is used. This means that implementations are required
to support portions of the GML specification that are not and, in
some cases, cannot be used.
GML is structured to be used within an application schema. An
application schema being a schema constructed for a particular
application that both limits GML to what is applicable and provides
application-specific types. PIDF-LO does not define such a schema.
As a result this increases the complexity of implementation and
decreases the usability of GML within PIDF-LO. If PIDF-LO is to be
usable in the internet domain, it requires that such a schema is
defined.
This document defines an application schema and profile for using GML
within PIDF-LO. This includes a small subset of GML geometry that is
expanded by a new schema that defines additional geometries.
These geometries, or shapes, are designed to provide a simple
representation of shapes that are in common usage. In particular,
these shapes are useful for the representation of uncertainty that
arises from location determination technologies. A range of these
shapes arise from wireless location technologies, and others are
suited to geodetic representations of civic features, such as
buildings and residental allotments. These shapes enable easy
translation from location information in other document formats into
the PIDF-LO form.
This document also updates the PIDF-LO specification [RFC4119] to
state that the geometry specified in this document is the only
requirement for geodetic shapes.
Thomson Expires June 16, 2007 [Page 4]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
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].
This document uses geodesy and mathematics terminology. While this
has been limited as far as is practical, some degree of familiarity
with these disciplines and their terminology is helpful. In
particular, terminology following the definitions in GML 3.1.1
[OGC.GML-3.1.1] is used.
When referring to XML element, attribute and type definitions by
name, this document uses namespace prefixes to distinguish between
elements in different namespaces. The "gml:" prefix refers to
elements from the "http://www.opengis.net/gml" namespace
[OGC.GML-3.1.1]; the "gs:" prefix refers to elements from the
"urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" namespace.
Thomson Expires June 16, 2007 [Page 5]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
3. Overview
PIDF-LO serves as a document for the representation of Location
Information (LI). This LI identifies the spatial location of a
Target; the Target being a generic entity that is likely to be either
a person or a Device. LI is a component of the Target's presence
information.
The LI that forms the core of a PIDF-LO document originates in the
Location Generator (LG). Depending on the specific circumstances,
particularly the type of access network, the LG can use any number of
methods to determine LI. The range of technologies available for
determining LI are numerous and range from user-provided LI, to
automatic methods such as wire mapping, radio timing, and GPS.
PIDF-LO is designed to be consumed in a wide range of applications.
In some cases the information is presented to a user, maybe in a
graphical representation, as a way of identifying the location of the
Target. Other applications use LI as input to assist in providing a
service.
3.1. About Location Information
Two forms of LI are defined for use in PIDF-LO. Geodetic information
consists of coordinates that identify a location in a particular
coordinate reference system; and civic addresses
[I-D.ietf-geopriv-revised-civic-lo] that identify a location based on
civic norms (countries, cities, streets, etc...). This document is
concerned with geodetic LI only.
The remainder of this section introduces location concepts that
affect how geodetic LI is represented and interpreted.
3.1.1. Coordinate Reference Systems
A coordinate reference system (CRS) specifies how coordinates are
interpreted. For the shapes defined in thie document, only the two-
and three-dimensional WGS84 coordinate reference systems (latitude,
longitude, and perhaps altitude) are mandatory, see Section 4.2. The
shapes defined in this document assume one or both of these CRSs and
may not be applicable to other coordinate reference systems.
3.1.2. Uncertainty
Under ideal circumstances LI would describe a point in space
unambiguously. However, in reality, location determination methods
are imprecise for a variety of reasons.
Thomson Expires June 16, 2007 [Page 6]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Uncertainty can be quantified in measurement in a number of ways,
usually depending on the method that is used to determine LI. An
area or volume is the most common way of representing uncertainty.
For example, an ellipsoid is common for representing uncertainty in
GPS measurements; polygons may be used when LI is converted from a
civic address form; or a circle or ellipse is often used to describe
the coverage area of a radio antenna.
Even if location determination results in a single point, uncertainty
may be specified as a distance from that point. This form of
uncertainty indicates the furthest distance from the given point that
the actual Target is expected to be located given certain sources of
measurement error. This still effectively defines a circular area,
or spherical volume, in which the Target could be located.
This document assumes that any method for determining location is
subject to uncertainty. The absence of uncertainty does not indicate
that there is none, or that the measurement was infinitely precise;
instead, the absence of uncertainty data indicates that the value of
uncertainty could not be (or was not) provided.
3.1.3. Confidence
Confidence is also used in some cases to express the innate
variability of location determination. Variability in determining
location cannot always be addressed by uncertainty. Confidence is a
statistical measure indicating the probability that the given region
of uncertainty actually covers the Target's actual location.
Confidence is typically affected by variation in measurement
parameters. However, confidence can also account for the chance of
human error in the form of data entry errors or exceptional software
faults. Likewise, confidence can cover the probability of
intentional modification of LI (location fraud) beyond the capability
of providers or protocol to prevent.
The application of confidence is controversial. Location
determination methods do not often directly provide this sort of
information, and likewise many applications do not use the value in
any way. In most cases the confidence cannot be used to make a
decision. For instance, one such decision that uses confidence is
whether or not the LI can be used; however, many applications rely on
the assumption that any LI is better than none, so uncertainty is not
considered.
Because uncertainty is difficult to manage, this document does not
include a parameter for conveying confidence. Individual
applications MAY recommend a target level of confidence, but this
Thomson Expires June 16, 2007 [Page 7]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
information is not included in the core geodetic shape formats.
Thomson Expires June 16, 2007 [Page 8]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
4. General Information
4.1. GML Version and Profile
This document is based on the version 3.1.1 schema of GML
[OGC.GML-3.1.1]. This version updates RFC 4119 [RFC4119].
This document restricts the required set of GML. A profile schema is
included in Section 7. This profile follows the guidelines of
[OGC.GML-3.1.1], it is a copy of the GML schema with portions
removed. GML compliant implementations MAY use the full GML schema
or the "geometryPrimitives.xsd" schema in place of this profile, as
identified by
"urn:opengis:specification:gml:schema-xsd:geometryPrimitives:3.1.1".
The GML profile defined in Section 7 removes all unused parts of GML
from the schema definition. In particular, this includes cross
references using XLink [W3C.REC-xlink-20010627]. The "gml:id"
attribute is retained so that geometry objects MAY still be the
target of a reference.
4.2. Coordinate Reference Systems
Implementations are REQUIRED to support the following coordinate
reference systems based on WGS 84 [NIMA.TR8350.2-3e]. These are
identified using the European Petroleum Survey Group (EPSG) Geodetic
Parameter Dataset, as formalized by the Open Geospatial Consortium
(OGC):
3D: WGS 84 (latitude, longitude, altitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS.
2D: WGS 84 (latitude, longitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.
The most recent version of the EPSG Geodetic Parameter Dataset SHOULD
be used. A CRS MUST be specified using the above URN notation only,
implementations do not need to support user-defined CRSs.
Implementations MUST specify the CRS using the "srsName" attribute on
the outermost geometry element. The CRS MUST NOT be respecified or
changed for any sub-elements. The "srsDimension" attribute SHOULD be
omitted, since the number of dimensions in these CRSs is known.
4.3. Units of Measure
GML permits a range of units of measure for all parameters. This
document restricts this set to a single length unit and two angle
Thomson Expires June 16, 2007 [Page 9]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
units.
Length measures MUST be specified using metres, which is identified
using the URN "urn:ogc:def:uom:EPSG::9001".
Angular measures MUST use either degrees or radians. Measures in
degrees MUST be identified by the URN "urn:ogc:def:uom:EPSG::9102".
Measures in radians MUST be identified by the URN
"urn:ogc:def:uom:EPSG::9101".
The units of measure MUST be specified on the property element that
contains the value.
4.4. Approximations
The shapes provided in this document are primarily intended to
represent areas of uncertainty. Uncertainty is a product of the
inexact science of determining a location estimate. These estimates
are subject to a range of errors. For these shapes, using
approximations in processing this data does not significantly affect
the quality of the data.
Several approximation methods are described in this document that can
be used to reduce the complexity of algorithms that use these shapes.
Applications and algorithms that rely on this data SHOULD tolerate
small errors that could arise from approximation.
The guidance in this document on approximation techniques are not
appropriate for shapes that cover large areas, or for applications
where greater precision is required. Any guidance on approximations
is appropriate to the application of these shapes to personal
location, but might not be appropriate in other application domains.
4.4.1. Lines and Distances
In this document, all lines and measurements are formed by straight
lines. When joining two points, linear interpolation is used, that
is, the shortest path in space rather than the path across the
surface of the ellipsoid (geodesic interpolation). Likewise for
distances, the distance is the length of the shortest path in space.
Implementations MAY use geodesic interpolation between points and for
distance measurement. A geodesic is a line that follows the surface
of a geoid or ellipsoid, which in this context is usually the WGS 84
ellipsoid. Geodesic interpolation can produce a small difference
from straight line interpolation. For use in uncertainty this error
can be accepted, but it is RECOMMENDED that this variation is
constrained to approximately 3% of the total distance.
Thomson Expires June 16, 2007 [Page 10]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
For WGS84, the error between a geodesic and a straight line reaches
3% of the distance of the line at approximately 382km at the equator.
This distance becomes approximately 131km in the East-West direction
at 70 degrees latitude (North or South). Therefore, for the
representation of uncertainty it is RECOMMENDED that the maximum
distance between two points in a shape be less than 130km. Shapes
that have an absolute latitude of more than 70 degrees SHOULD be
smaller before any approximation is used.
4.4.2. Planar Approximation
A common approximation used for geodesy applications treats the
surface of the ellipsoid as if it were a plane over a small area.
This approximation is more intuitive and simplifies mathematical
operations. Implementations MAY use this approximation method in
interpreting the shapes in this document providing that the size of
the shape is within the guidelines in Section 4.4.1.
Thomson Expires June 16, 2007 [Page 11]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
5. Geometry
This document defines a set of geometry that is appropriate for the
encoding of the sorts of LI described in Section 3.1. This section
describes how geometries can be represented using the application
schema defined in Section 6. Pre-existing GML geometries,
"gml:Point" and "gml:Polygon" are also described with examples.
This section clarifies the usage of the zero dimensional Point
(Section 5.1). The following two dimensional shapes are either
clarified or defined: Polygon (Section 5.2), Circle (Section 5.3),
Ellipse (Section 5.4) and Arc Band (Section 5.5). The following
three dimensional shapes are defined: Sphere (Section 5.6), Ellipsoid
(Section 5.7) and Prism (Section 5.8).
A description of the Point, Circle, Ellipse, Sphere, Ellipsoid,
Polygon and Arc Band, including descriptions of their parameters and
explanatory diagrams, can be found in [3GPP.TS23032].
5.1. Point
The point shape type is the simplest form of geodetic LI, which is
natively supported by GML. The "gml:Point" element is used when
there is no known uncertainty. A point also forms part of a number
of other geometries.
A point MAY be specified using either WGS 84 (latitude, longitude) or
WGS 84 (latitude, longitude, altitude). This is shown in the
following examples:
-34.407 150.883
-34.407 150.883 24.8
5.2. Polygon
A polygon uses the "gml:Polygon" element. A polygon is specified by
a sequence of points. A polygon requires at least four points, where
the first and last point MUST be the same.
Points specified in a polygon MUST be coplanar. However,
implementations SHOULD be prepared to accept small variations that
Thomson Expires June 16, 2007 [Page 12]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
might occur depending on whether the the polygon is specified on a
plane in space, or only relative to the ellipsoid. To avoid
implementation complexity, implementations MAY choose to not support
polygons that include varying altitude. Therefore, two polygon forms
are permitted: polygons specified using EPSG 4326, and polygons
specified using EPSG 4979 with a constant altitude value.
Interpolation between points is linear, as defined for the
"gml:LinearRing" element. Note that this interpolation is different
for that specified in [3GPP.TS23032], which uses geodesic
interpolation. Since geodesic interpolation is non-trivial to
implement and some error is acceptable in both [3GPP.TS23032] and
this document, implementations SHOULD minimize this error by ensuring
that the sides of polygons are as short as possible.
Note: [3GPP.TS23032] limits the number of unique points to 15 for a
polygon. Therefore, if interoperability is required, polygons should
not have more than 16 points in total.
The following example shows a polygon that is specified using EPSG
4326 and the "gml:pos" element. No altitude is included in this
example, indicating that altitude is unknown.
42.556844 -73.248157
42.549631 -73.237283
42.539087 -73.240328
42.535756 -73.254242
42.542969 -73.265115
42.553513 -73.262075
42.556844 -73.248157
Thomson Expires June 16, 2007 [Page 13]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
The following alternative example shows the same polygon with a
constant altitude included that is specified using EPSG 4979 and the
"gml:posList" element.
42.556844 -73.248157 36.6
42.549631 -73.237283 36.6
42.539087 -73.240328 36.6
42.535756 -73.254242 36.6
42.542969 -73.265115 36.6
42.553513 -73.262075 36.6
42.556844 -73.248157 36.6
The "gml:posList" element is interpreted as a list with the dimension
of the CRS indicating how many values are required for each point.
5.2.1. Polygon Upward Normal
The upward normal of a polygon determines the orientation of the
surface. The upward normal of a polygon is important for the
definition of the Prism (Section 5.8).
[OGC.GML-3.1.1] describes the upward normal of a surface as a unit
vector pointing to the side of the surface from which the exterior
boundary appears counterclockwise. It is RECOMMENDED therefore that
polygons are specified in a counterclockwise direction, so that their
upward normal corresponds to an actual _up_.
The upward normal can also be determined using the _Right Hand Rule_.
Take your right hand and curl the fingers in the predominant
direction that the polygon is defined; your thumb then points in the
direction of the upward normal.
Polygons with four or more unique points that are specified with
constant altitude are unlikely to be perfectly coplanar. An
approximate method for determining the upward normal of a polygon
that is not guaranteed to be coplanar is described in Appendix A.
Thomson Expires June 16, 2007 [Page 14]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
5.3. Circle
The circular area is used for coordinates in two-dimensional CRSs to
describe uncertainty about a point. The definition is based on the
one-dimensional geometry in GML, "gml:CircleByCenterPoint".
The centre point of a circular area MUST be specified using a two
dimensional CRS; in three dimensions, the orientation of the circle
cannot be specified correctly using this representation. A point
with uncertainty that is specified in three dimensions SHOULD use the
Sphere (Section 5.6) shape type.
42.5463 -73.2512
850.24
5.4. Ellipse
An elliptical area describes an ellipse in two dimensional space.
The ellipse is described by a center point, the length of its semi-
major and semi-minor axes, and the orientation of the semi-major
axis.
Like the circular area (Section 5.3), the ellipse MUST be specified
using a two dimensional CRS.
42.5463 -73.2512
1275
670
43.2
Thomson Expires June 16, 2007 [Page 15]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
The "gml:pos" element indicates the position of the center, or
origin, of the ellipse.
The "gs:semiMajorAxis" and "gs:semiMinorAxis" elements are the length
of the semi-major and semi-minor axes respectively.
The "gs:orientation" element is the angle by which the semi-major
axis is rotated from the first axis of the CRS towards the second
axis. For WGS 84, the orientation indicates rotation from Northing
to Easting, which, if specified in degrees, is roughly equivalent to
a compass bearing (if magnetic north were the same as the WGS north
pole).
Note: An ellipse with equal major and minor axis lengths is a circle.
5.5. Arc Band
An arc band is a section of a circular area that is constrained to an
arc between two radii. The arc band shape is most useful when radio
timing technologies are used to determine location, based on a single
wireless transmitter. These technologies provide a result that is a
range from the transmitter, which might also be constrained in
direction.
An arc band is defined by the center point of the circle, an inner
and outer radius, a start angle, and an opening angle.
The following figure shows a sample arc band, with the center point
"c", inner radius "r(i)", outer radius "r(o)", start angle "a(s)",
and opening angle "a(o)" indicated.
Thomson Expires June 16, 2007 [Page 16]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
N ^ ,.__
| / `-.
| a(s) / `-.
|--. / `.
| `/ \
| /__ \
| . `-. \
| . `. \
|. \ \ .
---c-- a(o) -- | | -->
|. / ' | E
| . / '
| . / ;
.,' /
r(i)`. /
`. /
`. ,'
`. ,'
r(o)`'
Arc Band Diagram
The center point, "gml:pos", MUST be specified in a two dimensional
CRS.
The inner radius, "gs:innerRadius", defines the minimum distance from
the center point. The outer radius, "gs:outerRadius", defines the
maximum distance from the center point.
The start angle, "gs:startAngle", and opening angles,
"gs:openingAngle", define where the arc begins and ends. The arc
covers an arc the size of the opening (or included) angle that begins
at the start (or offset) angle. Angles are measured clockwise from
North (Northing to Easting).
Thomson Expires June 16, 2007 [Page 17]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
The following example includes an arc band shape. This arc band
starts at 266 degrees and has a 120 degree opening; therefore, the
end of the band is at a 26 degree bearing.
42.5463 -73.2512
1661.55
2215.4
266
120
Note: An arc band with an inner radius of zero, and equal start and
opening angles is a circle.
5.6. Sphere
The sphere is a volume that provides the same information as a circle
(Section 5.3) in three dimensions. The sphere MUST be specified
using a three dimensional CRS.
The following example shows a sphere shape, which is identical to the
circle example, except for the addition of an altitude in the
provided coordinates.
42.5463 -73.2512 26.3
850.24
Thomson Expires June 16, 2007 [Page 18]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
5.7. Ellipsoid
The ellipsoid is a volume that is based on the ellipse (Section 5.4)
shape, with the addition of a third dimension. A single value,
vertical uncertainty, is added to the ellipse to form an ellipsoid.
A full specification of an ellipsoid would include three angles in
order to be able to orient the ellipsoid in three dimensions. This
representation is limited to a single orientation angle, which is the
same value that is used for the ellipse. This limits the major and
minor axes of the base ellipse to a plane that is parallel to the
surface of the WGS 84 ellipsoid at the given latitude and longitude.
Implementations MAY also choose to place these axes on the surface of
the WGS 84 ellipsoid. The difference between these two
interpretations are not considered significant.
The third length measurement, "gs:vertical", indicates the length of
the third axis of the ellipsoid, which is a line that is always
perpindicular to the surface of the WGS 84 ellipsoid, that is, it is
vertical.
This ellipsoid representation is similar to that described in
[3GPP.TS23032].
The following example shows an ellipsoid.
42.5463 -73.2512 26.3
7.7156
3.31
28.7
142
Note: An ellipsoid with equal major, minor and vertical axis lengths
is a sphere.
Thomson Expires June 16, 2007 [Page 19]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
5.8. Prism
The prism is a volume that is commonly used to represent a shape that
has a constant cross section along one axis. For the purposes of
PIDF-LO, a prism is most useful when representing a building, or
single floor of a building.
A prism is defined by its base, which is a two dimensional surface
specified using a three dimensional CRS, and a height. The height is
a scalar value that is projected in the direction of the upward
normal of the base surface, see Section 5.2.1.
It is strongly RECOMMENDED that the base shape for a prism is level,
that is, it exists at the same altitude for all points.
Implementations MAY reject prisms that have a base that is not at the
same altitude.
The following hexagonal prism might be used to represent a floor of a
building in geodetic form.
42.556844 -73.248157 36.6
42.549631 -73.237283 36.6
42.539087 -73.240328 36.6
42.535756 -73.254242 36.6
42.542969 -73.265115 36.6
42.553513 -73.262075 36.6
42.556844 -73.248157 36.6
2.4
The Circle (Section 5.3) and Ellipse (Section 5.4) shapes do not have
a defined upward normal, so they cannot be used as the base of a
Prism.
Thomson Expires June 16, 2007 [Page 20]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
6. Application Schema
GEOPRIV Geodetic Shapes
This document defines geodetic shape types for PIDF-LO.
Thomson Expires June 16, 2007 [Page 21]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 22]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 23]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
7. GML Profile Schema
This section defines a profile of GML that follows the
recommendations in Section 22 of [OGC.GML-3.1.1]. The _copy and
delete_ method has been employed to generate this schema. The
profile includes abridged versions of the files:
"geometryPrimitives.xsd", "geometryBasic2d.xsd",
"geometryBasic0d1d.xsd", "measures.xsd", "gmlBase.xsd", and
"basicTypes.xsd". Note that "units.xsd" and "dictionary.xsd" are
excluded from this profile.
For the purposes of brevity, all comments and annotations from the
original GML schema have been removed. Schematron [ISO.19757-3.2005]
validation has also been removed.
7.1. geometryPrimitives.xsd
The following file is the profile version of
"geometryPrimitives.xsd".
Thomson Expires June 16, 2007 [Page 24]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 25]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 26]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 27]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
7.2. geometryBasic2d.xsd
The following file is the profile version of "geometryBasic2d.xsd".
7.3. geometryBasic0d1d.xsd
The following file is the profile version of "geometryBasic0d1d.xsd".
Thomson Expires June 16, 2007 [Page 30]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 31]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Thomson Expires June 16, 2007 [Page 33]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
7.4. measures.xsd
The following file is the profile version of "measures.xsd".
Thomson Expires June 16, 2007 [Page 34]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
7.5. gmlBase.xsd
The following file is the profile version of "gmlBase.xsd".
Thomson Expires June 16, 2007 [Page 35]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
7.6. basicTypes.xsd
The following file is the profile version of "basicTypes.xsd".
Thomson Expires June 16, 2007 [Page 36]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
8. Security Considerations
It is believed that this document does not have any security
considerations. If this information is included within a PIDF-LO
document, the security considerations of [RFC4119] apply, especially
those that are related to privacy.
Thomson Expires June 16, 2007 [Page 37]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
9. IANA Considerations
This section registers the application schema for geodetic shapes and
its namespace with IANA.
9.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:geoShape
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:geoShape", as per the
guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:geoShape
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
GEOPRIV GML Application Schema
Namespace for GEOPRIV GML Application Schema
urn:ietf:params:xml:ns:pidf:geopriv10:geoShape
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:geoShape
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Thomson Expires June 16, 2007 [Page 38]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Schema: The XML for this schema can be found as the entirety of
Section 6 of this document.
Thomson Expires June 16, 2007 [Page 39]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
10. Acknowledgements
The author would like to thank Carl Reed and Ron Lake of the OGC for
their help in understanding geodesy and GML. The author would also
like to thank Cullen Jennings for asking intelligent questions when
noone else did.
Thomson Expires June 16, 2007 [Page 40]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[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,
.
11.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-04 (work in progress),
September 2006.
[W3C.REC-xlink-20010627]
DeRose, S., Orchard, D., and E. Maler, "XML Linking
Language (XLink) Version 1.0", World Wide Web Consortium
Recommendation REC-xlink-20010627, June 2001,
.
[NIMA.TR8350.2-3e]
US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition", NIMA TR8350.2, January 2000.
[EPSG.GN7-2]
European Petroleum Survey Group, "Coordinate Conversions
and Transforms including Formulas", EPSG Guidance Note 7,
part 2 , November 2005,
.
[3GPP.TS23032]
3GPP, "Universal Geographical Area Description (GAD)",
3GPP TS 23.032 v6.0.0, December 2004.
Thomson Expires June 16, 2007 [Page 41]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
[ISO.19757-3.2005]
International Organization for Standardization and
International Electrotechnical Commission, "Document
Schema Definitions Languages (DSDL): Part 3 - Rule-based
validation - Schematron", ISO/IEC FDIS 19757-3, 2005.
[Sunday02]
Sunday, D., "Fast polygon area and Newell normal
computation.", Journal of Graphics Tools JGT, 7(2):9-
13,2002, 2002, .
Thomson Expires June 16, 2007 [Page 42]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Appendix A. Calculating the Upward Normal of a Polygon
For a polygon that is guaranteed to be convex and coplanar, the
upward normal can be found by finding the vector cross product of
adjacent edges.
For more general cases the Newell method of approximation described
in [Sunday02] may be applied. In particular, this method can be used
if the points are only approximately coplanar, and for non-convex
polygons.
This method can be condensed to the following set of equations:
Ux := sum from i=1..n of (y[i] * (z[i+1] - z[i-1]))
Uy := sum from i=1..n of (z[i] * (x[i+1] - x[i-1]))
Uz := sum from i=1..n of (x[i] * (y[i+1] - y[i-1]))
For these formulae, the polygon is made of points (x[1], y[1], z[1])
through (x[n], y[n], x[n]). Each array is treated as circular, that
is, x[0] = x[n] and x[n+1] = x[1].
Note: This method assumes a cartesian coordinate system, this SHOULD
NOT be applied to coordinates specified in the WGS 84 (latitude,
longitude, altitude) CRS. Coordinates specified in a geographic CRS
SHOULD be transformed to a cartesian, geocentric CRS (such as EPSG
4978) before this method is applied, see [EPSG.GN7-2] and
[NIMA.TR8350.2-3e] for details.
Thomson Expires June 16, 2007 [Page 43]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Appendix B. Change Log
[[The RFC Editor is requested to remove this section at
publication.]]
Changes since draft-thomson-geopriv-geo-shape-02:
o Corrected typographical errors.
Changes since -01:
o Added more guidance on applicability.
o Added more guidance on approximations methods and the limits to
those methods.
Changes since -00:
o Removed 16 point limit on Polygons.
o Resolved outstanding issues (no changes).
Thomson Expires June 16, 2007 [Page 44]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Author's Address
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Thomson Expires June 16, 2007 [Page 45]
Internet-Draft PIDF-LO Geodetic Shapes December 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Thomson Expires June 16, 2007 [Page 46]