idnits 2.17.1
draft-thomson-geopriv-geo-shape-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 14.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1639.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1650.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1657.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1663.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 13, 2006) is 6344 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '1' on line 1582
-- Looks like a reference, but probably isn't: '0' on line 1582
== Outdated reference: A later version (-07) exists of
draft-ietf-geopriv-revised-civic-lo-04
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft Andrew
4 Expires: June 16, 2007 December 13, 2006
6 Geodetic Shapes for the Representation of Uncertainty in PIDF-LO
7 draft-thomson-geopriv-geo-shape-03.txt
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on June 16, 2007.
34 Copyright Notice
36 Copyright (C) The IETF Trust (2006).
38 Abstract
40 This document defines a set of shapes for the representation of
41 uncertainty for PIDF-LO geodetic location information. This includes
42 a GML profile and a schema that defines additional geometries.
43 Further recommendations are made to restrict the use of geographic
44 Coordinate Reference Systems (CRS) and units of measure restrictions
45 that improve interoperability.
47 Table of Contents
49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
50 2. Conventions used in this document . . . . . . . . . . . . . . 5
51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
52 3.1. About Location Information . . . . . . . . . . . . . . . . 6
53 3.1.1. Coordinate Reference Systems . . . . . . . . . . . . . 6
54 3.1.2. Uncertainty . . . . . . . . . . . . . . . . . . . . . 6
55 3.1.3. Confidence . . . . . . . . . . . . . . . . . . . . . . 7
56 4. General Information . . . . . . . . . . . . . . . . . . . . . 9
57 4.1. GML Version and Profile . . . . . . . . . . . . . . . . . 9
58 4.2. Coordinate Reference Systems . . . . . . . . . . . . . . . 9
59 4.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 9
60 4.4. Approximations . . . . . . . . . . . . . . . . . . . . . . 10
61 4.4.1. Lines and Distances . . . . . . . . . . . . . . . . . 10
62 4.4.2. Planar Approximation . . . . . . . . . . . . . . . . . 11
63 5. Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
64 5.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 12
65 5.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 12
66 5.2.1. Polygon Upward Normal . . . . . . . . . . . . . . . . 14
67 5.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . . . 15
68 5.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . . . 15
69 5.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . . . 16
70 5.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 18
71 5.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . . . 19
72 5.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . . . 20
73 6. Application Schema . . . . . . . . . . . . . . . . . . . . . . 21
74 7. GML Profile Schema . . . . . . . . . . . . . . . . . . . . . . 24
75 7.1. geometryPrimitives.xsd . . . . . . . . . . . . . . . . . . 24
76 7.2. geometryBasic2d.xsd . . . . . . . . . . . . . . . . . . . 28
77 7.3. geometryBasic0d1d.xsd . . . . . . . . . . . . . . . . . . 30
78 7.4. measures.xsd . . . . . . . . . . . . . . . . . . . . . . . 34
79 7.5. gmlBase.xsd . . . . . . . . . . . . . . . . . . . . . . . 35
80 7.6. basicTypes.xsd . . . . . . . . . . . . . . . . . . . . . . 36
81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
83 9.1. URN Sub-Namespace Registration for
84 urn:ietf:params:xml:ns:pidf:geopriv10:geoShape . . . . . . 38
85 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 38
86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
89 11.2. Informative References . . . . . . . . . . . . . . . . . . 41
90 Appendix A. Calculating the Upward Normal of a Polygon . . . . . 43
91 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44
92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45
93 Intellectual Property and Copyright Statements . . . . . . . . . . 46
95 1. Introduction
97 This document defines how geodetic location information is specified
98 in a PIDF-LO [RFC4119] document.
100 PIDF-LO [RFC4119] specifies that the feature schema from version 3.0
101 of GML be supported by all implementations. However, this is not
102 practical for a number of reasons.
104 The feature schema, and the schema that it relies upon, includes a
105 sizable proportion of the GML data types. This includes parts of the
106 geometry and temporal schema that are rarely applicable in the domain
107 where PIDF-LO is used. This means that implementations are required
108 to support portions of the GML specification that are not and, in
109 some cases, cannot be used.
111 GML is structured to be used within an application schema. An
112 application schema being a schema constructed for a particular
113 application that both limits GML to what is applicable and provides
114 application-specific types. PIDF-LO does not define such a schema.
115 As a result this increases the complexity of implementation and
116 decreases the usability of GML within PIDF-LO. If PIDF-LO is to be
117 usable in the internet domain, it requires that such a schema is
118 defined.
120 This document defines an application schema and profile for using GML
121 within PIDF-LO. This includes a small subset of GML geometry that is
122 expanded by a new schema that defines additional geometries.
124 These geometries, or shapes, are designed to provide a simple
125 representation of shapes that are in common usage. In particular,
126 these shapes are useful for the representation of uncertainty that
127 arises from location determination technologies. A range of these
128 shapes arise from wireless location technologies, and others are
129 suited to geodetic representations of civic features, such as
130 buildings and residental allotments. These shapes enable easy
131 translation from location information in other document formats into
132 the PIDF-LO form.
134 This document also updates the PIDF-LO specification [RFC4119] to
135 state that the geometry specified in this document is the only
136 requirement for geodetic shapes.
138 2. Conventions used in this document
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
142 document are to be interpreted as described in [RFC2119].
144 This document uses geodesy and mathematics terminology. While this
145 has been limited as far as is practical, some degree of familiarity
146 with these disciplines and their terminology is helpful. In
147 particular, terminology following the definitions in GML 3.1.1
148 [OGC.GML-3.1.1] is used.
150 When referring to XML element, attribute and type definitions by
151 name, this document uses namespace prefixes to distinguish between
152 elements in different namespaces. The "gml:" prefix refers to
153 elements from the "http://www.opengis.net/gml" namespace
154 [OGC.GML-3.1.1]; the "gs:" prefix refers to elements from the
155 "urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" namespace.
157 3. Overview
159 PIDF-LO serves as a document for the representation of Location
160 Information (LI). This LI identifies the spatial location of a
161 Target; the Target being a generic entity that is likely to be either
162 a person or a Device. LI is a component of the Target's presence
163 information.
165 The LI that forms the core of a PIDF-LO document originates in the
166 Location Generator (LG). Depending on the specific circumstances,
167 particularly the type of access network, the LG can use any number of
168 methods to determine LI. The range of technologies available for
169 determining LI are numerous and range from user-provided LI, to
170 automatic methods such as wire mapping, radio timing, and GPS.
172 PIDF-LO is designed to be consumed in a wide range of applications.
173 In some cases the information is presented to a user, maybe in a
174 graphical representation, as a way of identifying the location of the
175 Target. Other applications use LI as input to assist in providing a
176 service.
178 3.1. About Location Information
180 Two forms of LI are defined for use in PIDF-LO. Geodetic information
181 consists of coordinates that identify a location in a particular
182 coordinate reference system; and civic addresses
183 [I-D.ietf-geopriv-revised-civic-lo] that identify a location based on
184 civic norms (countries, cities, streets, etc...). This document is
185 concerned with geodetic LI only.
187 The remainder of this section introduces location concepts that
188 affect how geodetic LI is represented and interpreted.
190 3.1.1. Coordinate Reference Systems
192 A coordinate reference system (CRS) specifies how coordinates are
193 interpreted. For the shapes defined in thie document, only the two-
194 and three-dimensional WGS84 coordinate reference systems (latitude,
195 longitude, and perhaps altitude) are mandatory, see Section 4.2. The
196 shapes defined in this document assume one or both of these CRSs and
197 may not be applicable to other coordinate reference systems.
199 3.1.2. Uncertainty
201 Under ideal circumstances LI would describe a point in space
202 unambiguously. However, in reality, location determination methods
203 are imprecise for a variety of reasons.
205 Uncertainty can be quantified in measurement in a number of ways,
206 usually depending on the method that is used to determine LI. An
207 area or volume is the most common way of representing uncertainty.
208 For example, an ellipsoid is common for representing uncertainty in
209 GPS measurements; polygons may be used when LI is converted from a
210 civic address form; or a circle or ellipse is often used to describe
211 the coverage area of a radio antenna.
213 Even if location determination results in a single point, uncertainty
214 may be specified as a distance from that point. This form of
215 uncertainty indicates the furthest distance from the given point that
216 the actual Target is expected to be located given certain sources of
217 measurement error. This still effectively defines a circular area,
218 or spherical volume, in which the Target could be located.
220 This document assumes that any method for determining location is
221 subject to uncertainty. The absence of uncertainty does not indicate
222 that there is none, or that the measurement was infinitely precise;
223 instead, the absence of uncertainty data indicates that the value of
224 uncertainty could not be (or was not) provided.
226 3.1.3. Confidence
228 Confidence is also used in some cases to express the innate
229 variability of location determination. Variability in determining
230 location cannot always be addressed by uncertainty. Confidence is a
231 statistical measure indicating the probability that the given region
232 of uncertainty actually covers the Target's actual location.
234 Confidence is typically affected by variation in measurement
235 parameters. However, confidence can also account for the chance of
236 human error in the form of data entry errors or exceptional software
237 faults. Likewise, confidence can cover the probability of
238 intentional modification of LI (location fraud) beyond the capability
239 of providers or protocol to prevent.
241 The application of confidence is controversial. Location
242 determination methods do not often directly provide this sort of
243 information, and likewise many applications do not use the value in
244 any way. In most cases the confidence cannot be used to make a
245 decision. For instance, one such decision that uses confidence is
246 whether or not the LI can be used; however, many applications rely on
247 the assumption that any LI is better than none, so uncertainty is not
248 considered.
250 Because uncertainty is difficult to manage, this document does not
251 include a parameter for conveying confidence. Individual
252 applications MAY recommend a target level of confidence, but this
253 information is not included in the core geodetic shape formats.
255 4. General Information
257 4.1. GML Version and Profile
259 This document is based on the version 3.1.1 schema of GML
260 [OGC.GML-3.1.1]. This version updates RFC 4119 [RFC4119].
262 This document restricts the required set of GML. A profile schema is
263 included in Section 7. This profile follows the guidelines of
264 [OGC.GML-3.1.1], it is a copy of the GML schema with portions
265 removed. GML compliant implementations MAY use the full GML schema
266 or the "geometryPrimitives.xsd" schema in place of this profile, as
267 identified by
268 "urn:opengis:specification:gml:schema-xsd:geometryPrimitives:3.1.1".
270 The GML profile defined in Section 7 removes all unused parts of GML
271 from the schema definition. In particular, this includes cross
272 references using XLink [W3C.REC-xlink-20010627]. The "gml:id"
273 attribute is retained so that geometry objects MAY still be the
274 target of a reference.
276 4.2. Coordinate Reference Systems
278 Implementations are REQUIRED to support the following coordinate
279 reference systems based on WGS 84 [NIMA.TR8350.2-3e]. These are
280 identified using the European Petroleum Survey Group (EPSG) Geodetic
281 Parameter Dataset, as formalized by the Open Geospatial Consortium
282 (OGC):
284 3D: WGS 84 (latitude, longitude, altitude), as identified by the URN
285 "urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS.
287 2D: WGS 84 (latitude, longitude), as identified by the URN
288 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.
290 The most recent version of the EPSG Geodetic Parameter Dataset SHOULD
291 be used. A CRS MUST be specified using the above URN notation only,
292 implementations do not need to support user-defined CRSs.
294 Implementations MUST specify the CRS using the "srsName" attribute on
295 the outermost geometry element. The CRS MUST NOT be respecified or
296 changed for any sub-elements. The "srsDimension" attribute SHOULD be
297 omitted, since the number of dimensions in these CRSs is known.
299 4.3. Units of Measure
301 GML permits a range of units of measure for all parameters. This
302 document restricts this set to a single length unit and two angle
303 units.
305 Length measures MUST be specified using metres, which is identified
306 using the URN "urn:ogc:def:uom:EPSG::9001".
308 Angular measures MUST use either degrees or radians. Measures in
309 degrees MUST be identified by the URN "urn:ogc:def:uom:EPSG::9102".
310 Measures in radians MUST be identified by the URN
311 "urn:ogc:def:uom:EPSG::9101".
313 The units of measure MUST be specified on the property element that
314 contains the value.
316 4.4. Approximations
318 The shapes provided in this document are primarily intended to
319 represent areas of uncertainty. Uncertainty is a product of the
320 inexact science of determining a location estimate. These estimates
321 are subject to a range of errors. For these shapes, using
322 approximations in processing this data does not significantly affect
323 the quality of the data.
325 Several approximation methods are described in this document that can
326 be used to reduce the complexity of algorithms that use these shapes.
327 Applications and algorithms that rely on this data SHOULD tolerate
328 small errors that could arise from approximation.
330 The guidance in this document on approximation techniques are not
331 appropriate for shapes that cover large areas, or for applications
332 where greater precision is required. Any guidance on approximations
333 is appropriate to the application of these shapes to personal
334 location, but might not be appropriate in other application domains.
336 4.4.1. Lines and Distances
338 In this document, all lines and measurements are formed by straight
339 lines. When joining two points, linear interpolation is used, that
340 is, the shortest path in space rather than the path across the
341 surface of the ellipsoid (geodesic interpolation). Likewise for
342 distances, the distance is the length of the shortest path in space.
344 Implementations MAY use geodesic interpolation between points and for
345 distance measurement. A geodesic is a line that follows the surface
346 of a geoid or ellipsoid, which in this context is usually the WGS 84
347 ellipsoid. Geodesic interpolation can produce a small difference
348 from straight line interpolation. For use in uncertainty this error
349 can be accepted, but it is RECOMMENDED that this variation is
350 constrained to approximately 3% of the total distance.
352 For WGS84, the error between a geodesic and a straight line reaches
353 3% of the distance of the line at approximately 382km at the equator.
354 This distance becomes approximately 131km in the East-West direction
355 at 70 degrees latitude (North or South). Therefore, for the
356 representation of uncertainty it is RECOMMENDED that the maximum
357 distance between two points in a shape be less than 130km. Shapes
358 that have an absolute latitude of more than 70 degrees SHOULD be
359 smaller before any approximation is used.
361 4.4.2. Planar Approximation
363 A common approximation used for geodesy applications treats the
364 surface of the ellipsoid as if it were a plane over a small area.
365 This approximation is more intuitive and simplifies mathematical
366 operations. Implementations MAY use this approximation method in
367 interpreting the shapes in this document providing that the size of
368 the shape is within the guidelines in Section 4.4.1.
370 5. Geometry
372 This document defines a set of geometry that is appropriate for the
373 encoding of the sorts of LI described in Section 3.1. This section
374 describes how geometries can be represented using the application
375 schema defined in Section 6. Pre-existing GML geometries,
376 "gml:Point" and "gml:Polygon" are also described with examples.
378 This section clarifies the usage of the zero dimensional Point
379 (Section 5.1). The following two dimensional shapes are either
380 clarified or defined: Polygon (Section 5.2), Circle (Section 5.3),
381 Ellipse (Section 5.4) and Arc Band (Section 5.5). The following
382 three dimensional shapes are defined: Sphere (Section 5.6), Ellipsoid
383 (Section 5.7) and Prism (Section 5.8).
385 A description of the Point, Circle, Ellipse, Sphere, Ellipsoid,
386 Polygon and Arc Band, including descriptions of their parameters and
387 explanatory diagrams, can be found in [3GPP.TS23032].
389 5.1. Point
391 The point shape type is the simplest form of geodetic LI, which is
392 natively supported by GML. The "gml:Point" element is used when
393 there is no known uncertainty. A point also forms part of a number
394 of other geometries.
396 A point MAY be specified using either WGS 84 (latitude, longitude) or
397 WGS 84 (latitude, longitude, altitude). This is shown in the
398 following examples:
400
1409
1413
1417
1421
1433
See RFCXXXX.
1477 1478 1479 END 1481 9.2. XML Schema Registration 1483 This section registers an XML schema as per the guidelines in 1484 [RFC3688]. 1486 URI: urn:ietf:params:xml:schema:pidf:geopriv10:geoShape 1488 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1489 Martin Thomson (martin.thomson@andrew.com). 1491 Schema: The XML for this schema can be found as the entirety of 1492 Section 6 of this document. 1494 10. Acknowledgements 1496 The author would like to thank Carl Reed and Ron Lake of the OGC for 1497 their help in understanding geodesy and GML. The author would also 1498 like to thank Cullen Jennings for asking intelligent questions when 1499 noone else did. 1501 11. References 1503 11.1. Normative References 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, March 1997. 1508 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1509 Format", RFC 4119, December 2005. 1511 [OGC.GML-3.1.1] 1512 Cox, S., Daisey, P., Lake, R., Portele, C., and A. 1513 Whiteside, "Geographic information - Geography Markup 1514 Language (GML)", OpenGIS 03-105r1, April 2004, 1515