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 402 -34.407 150.883 403 405 407 -34.407 150.883 24.8 408 410 5.2. Polygon 412 A polygon uses the "gml:Polygon" element. A polygon is specified by 413 a sequence of points. A polygon requires at least four points, where 414 the first and last point MUST be the same. 416 Points specified in a polygon MUST be coplanar. However, 417 implementations SHOULD be prepared to accept small variations that 418 might occur depending on whether the the polygon is specified on a 419 plane in space, or only relative to the ellipsoid. To avoid 420 implementation complexity, implementations MAY choose to not support 421 polygons that include varying altitude. Therefore, two polygon forms 422 are permitted: polygons specified using EPSG 4326, and polygons 423 specified using EPSG 4979 with a constant altitude value. 425 Interpolation between points is linear, as defined for the 426 "gml:LinearRing" element. Note that this interpolation is different 427 for that specified in [3GPP.TS23032], which uses geodesic 428 interpolation. Since geodesic interpolation is non-trivial to 429 implement and some error is acceptable in both [3GPP.TS23032] and 430 this document, implementations SHOULD minimize this error by ensuring 431 that the sides of polygons are as short as possible. 433 Note: [3GPP.TS23032] limits the number of unique points to 15 for a 434 polygon. Therefore, if interoperability is required, polygons should 435 not have more than 16 points in total. 437 The following example shows a polygon that is specified using EPSG 438 4326 and the "gml:pos" element. No altitude is included in this 439 example, indicating that altitude is unknown. 441 443 444 445 42.556844 -73.248157 446 42.549631 -73.237283 447 42.539087 -73.240328 448 42.535756 -73.254242 449 42.542969 -73.265115 450 42.553513 -73.262075 451 42.556844 -73.248157 452 453 454 456 The following alternative example shows the same polygon with a 457 constant altitude included that is specified using EPSG 4979 and the 458 "gml:posList" element. 460 462 463 464 465 42.556844 -73.248157 36.6 466 42.549631 -73.237283 36.6 467 42.539087 -73.240328 36.6 468 42.535756 -73.254242 36.6 469 42.542969 -73.265115 36.6 470 42.553513 -73.262075 36.6 471 42.556844 -73.248157 36.6 472 473 474 475 477 The "gml:posList" element is interpreted as a list with the dimension 478 of the CRS indicating how many values are required for each point. 480 5.2.1. Polygon Upward Normal 482 The upward normal of a polygon determines the orientation of the 483 surface. The upward normal of a polygon is important for the 484 definition of the Prism (Section 5.8). 486 [OGC.GML-3.1.1] describes the upward normal of a surface as a unit 487 vector pointing to the side of the surface from which the exterior 488 boundary appears counterclockwise. It is RECOMMENDED therefore that 489 polygons are specified in a counterclockwise direction, so that their 490 upward normal corresponds to an actual _up_. 492 The upward normal can also be determined using the _Right Hand Rule_. 493 Take your right hand and curl the fingers in the predominant 494 direction that the polygon is defined; your thumb then points in the 495 direction of the upward normal. 497 Polygons with four or more unique points that are specified with 498 constant altitude are unlikely to be perfectly coplanar. An 499 approximate method for determining the upward normal of a polygon 500 that is not guaranteed to be coplanar is described in Appendix A. 502 5.3. Circle 504 The circular area is used for coordinates in two-dimensional CRSs to 505 describe uncertainty about a point. The definition is based on the 506 one-dimensional geometry in GML, "gml:CircleByCenterPoint". 508 The centre point of a circular area MUST be specified using a two 509 dimensional CRS; in three dimensions, the orientation of the circle 510 cannot be specified correctly using this representation. A point 511 with uncertainty that is specified in three dimensions SHOULD use the 512 Sphere (Section 5.6) shape type. 514 517 518 42.5463 -73.2512 519 520 521 850.24 522 523 525 5.4. Ellipse 527 An elliptical area describes an ellipse in two dimensional space. 528 The ellipse is described by a center point, the length of its semi- 529 major and semi-minor axes, and the orientation of the semi-major 530 axis. 532 Like the circular area (Section 5.3), the ellipse MUST be specified 533 using a two dimensional CRS. 535 538 539 42.5463 -73.2512 540 541 542 1275 543 544 545 670 546 547 548 43.2 549 551 553 The "gml:pos" element indicates the position of the center, or 554 origin, of the ellipse. 556 The "gs:semiMajorAxis" and "gs:semiMinorAxis" elements are the length 557 of the semi-major and semi-minor axes respectively. 559 The "gs:orientation" element is the angle by which the semi-major 560 axis is rotated from the first axis of the CRS towards the second 561 axis. For WGS 84, the orientation indicates rotation from Northing 562 to Easting, which, if specified in degrees, is roughly equivalent to 563 a compass bearing (if magnetic north were the same as the WGS north 564 pole). 566 Note: An ellipse with equal major and minor axis lengths is a circle. 568 5.5. Arc Band 570 An arc band is a section of a circular area that is constrained to an 571 arc between two radii. The arc band shape is most useful when radio 572 timing technologies are used to determine location, based on a single 573 wireless transmitter. These technologies provide a result that is a 574 range from the transmitter, which might also be constrained in 575 direction. 577 An arc band is defined by the center point of the circle, an inner 578 and outer radius, a start angle, and an opening angle. 580 The following figure shows a sample arc band, with the center point 581 "c", inner radius "r(i)", outer radius "r(o)", start angle "a(s)", 582 and opening angle "a(o)" indicated. 584 N ^ ,.__ 585 | / `-. 586 | a(s) / `-. 587 |--. / `. 588 | `/ \ 589 | /__ \ 590 | . `-. \ 591 | . `. \ 592 |. \ \ . 593 ---c-- a(o) -- | | --> 594 |. / ' | E 595 | . / ' 596 | . / ; 597 .,' / 598 r(i)`. / 599 `. / 600 `. ,' 601 `. ,' 602 r(o)`' 604 Arc Band Diagram 606 The center point, "gml:pos", MUST be specified in a two dimensional 607 CRS. 609 The inner radius, "gs:innerRadius", defines the minimum distance from 610 the center point. The outer radius, "gs:outerRadius", defines the 611 maximum distance from the center point. 613 The start angle, "gs:startAngle", and opening angles, 614 "gs:openingAngle", define where the arc begins and ends. The arc 615 covers an arc the size of the opening (or included) angle that begins 616 at the start (or offset) angle. Angles are measured clockwise from 617 North (Northing to Easting). 619 The following example includes an arc band shape. This arc band 620 starts at 266 degrees and has a 120 degree opening; therefore, the 621 end of the band is at a 26 degree bearing. 623 626 627 42.5463 -73.2512 628 629 630 1661.55 631 632 633 2215.4 634 635 636 266 637 638 639 120 640 641 643 Note: An arc band with an inner radius of zero, and equal start and 644 opening angles is a circle. 646 5.6. Sphere 648 The sphere is a volume that provides the same information as a circle 649 (Section 5.3) in three dimensions. The sphere MUST be specified 650 using a three dimensional CRS. 652 The following example shows a sphere shape, which is identical to the 653 circle example, except for the addition of an altitude in the 654 provided coordinates. 656 659 660 42.5463 -73.2512 26.3 661 662 663 850.24 664 665 667 5.7. Ellipsoid 669 The ellipsoid is a volume that is based on the ellipse (Section 5.4) 670 shape, with the addition of a third dimension. A single value, 671 vertical uncertainty, is added to the ellipse to form an ellipsoid. 673 A full specification of an ellipsoid would include three angles in 674 order to be able to orient the ellipsoid in three dimensions. This 675 representation is limited to a single orientation angle, which is the 676 same value that is used for the ellipse. This limits the major and 677 minor axes of the base ellipse to a plane that is parallel to the 678 surface of the WGS 84 ellipsoid at the given latitude and longitude. 679 Implementations MAY also choose to place these axes on the surface of 680 the WGS 84 ellipsoid. The difference between these two 681 interpretations are not considered significant. 683 The third length measurement, "gs:vertical", indicates the length of 684 the third axis of the ellipsoid, which is a line that is always 685 perpindicular to the surface of the WGS 84 ellipsoid, that is, it is 686 vertical. 688 This ellipsoid representation is similar to that described in 689 [3GPP.TS23032]. 691 The following example shows an ellipsoid. 693 696 697 42.5463 -73.2512 26.3 698 699 700 7.7156 701 702 703 3.31 704 705 706 28.7 707 708 709 142 710 711 713 Note: An ellipsoid with equal major, minor and vertical axis lengths 714 is a sphere. 716 5.8. Prism 718 The prism is a volume that is commonly used to represent a shape that 719 has a constant cross section along one axis. For the purposes of 720 PIDF-LO, a prism is most useful when representing a building, or 721 single floor of a building. 723 A prism is defined by its base, which is a two dimensional surface 724 specified using a three dimensional CRS, and a height. The height is 725 a scalar value that is projected in the direction of the upward 726 normal of the base surface, see Section 5.2.1. 728 It is strongly RECOMMENDED that the base shape for a prism is level, 729 that is, it exists at the same altitude for all points. 730 Implementations MAY reject prisms that have a base that is not at the 731 same altitude. 733 The following hexagonal prism might be used to represent a floor of a 734 building in geodetic form. 736 739 740 741 742 743 744 42.556844 -73.248157 36.6 745 42.549631 -73.237283 36.6 746 42.539087 -73.240328 36.6 747 42.535756 -73.254242 36.6 748 42.542969 -73.265115 36.6 749 42.553513 -73.262075 36.6 750 42.556844 -73.248157 36.6 751 752 753 754 755 756 757 2.4 758 759 761 The Circle (Section 5.3) and Ellipse (Section 5.4) shapes do not have 762 a defined upward normal, so they cannot be used as the base of a 763 Prism. 765 6. Application Schema 767 768 776 777 779 GEOPRIV Geodetic Shapes 780 781 782 784 This document defines geodetic shape types for PIDF-LO. 785 786 788 791 793 794 795 796 797 798 799 800 801 802 804 806 807 808 809 810 811 812 813 814 815 816 817 819 821 822 823 824 825 826 827 828 829 830 831 832 833 835 837 838 839 840 841 842 843 844 845 846 848 850 851 852 853 854 855 856 857 858 859 860 862 863 864 865 866 867 868 869 870 871 872 873 874 876 877 878 879 880 881 883 885 7. GML Profile Schema 887 This section defines a profile of GML that follows the 888 recommendations in Section 22 of [OGC.GML-3.1.1]. The _copy and 889 delete_ method has been employed to generate this schema. The 890 profile includes abridged versions of the files: 891 "geometryPrimitives.xsd", "geometryBasic2d.xsd", 892 "geometryBasic0d1d.xsd", "measures.xsd", "gmlBase.xsd", and 893 "basicTypes.xsd". Note that "units.xsd" and "dictionary.xsd" are 894 excluded from this profile. 896 For the purposes of brevity, all comments and annotations from the 897 original GML schema have been removed. Schematron [ISO.19757-3.2005] 898 validation has also been removed. 900 7.1. geometryPrimitives.xsd 902 The following file is the profile version of 903 "geometryPrimitives.xsd". 905 906 911 913 915 916 917 918 919 920 921 922 923 925 927 928 929 931 933 935 937 938 939 940 942 943 945 947 948 949 950 951 952 953 954 955 956 957 958 959 961 962 963 965 967 968 969 970 971 972 973 974 975 976 978 980 981 984 986 987 988 990 993 994 995 996 997 999 1001 1002 1003 1004 1005 1006 1007 1008 1009 1011 1013 1014 1015 1017 1018 1019 1020 1021 1022 1024 1026 1027 1028 1029 1030 1031 1032 1035 1036 1037 1039 1041 1042 1043 1044 1045 1046 1047 1050 1051 1052 1054 1056 1057 1058 1059 1060 1061 1062 1063 1064 1066 1069 1070 1071 1072 1073 1074 1075 1076 1078 1080 1082 1083 1084 1085 1086 1088 1090 1091 1092 1093 1094 1096 1097 1098 1099 1101 1102 1103 1104 1105 1106 1107 1108 1110 1111 1112 1113 1114 1116 1118 7.2. geometryBasic2d.xsd 1120 The following file is the profile version of "geometryBasic2d.xsd". 1122 1123 1128 1130 1133 1134 1135 1136 1137 1139 1140 1141 1142 1143 1144 1146 1148 1149 1150 1151 1152 1153 1154 1155 1156 1158 1160 1161 1162 1163 1164 1166 1167 1168 1169 1170 1171 1173 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1191 1193 7.3. geometryBasic0d1d.xsd 1195 The following file is the profile version of "geometryBasic0d1d.xsd". 1197 1198 1203 1205 1207 1208 1209 1210 1211 1213 1214 1215 1217 1218 1220 1221 1222 1223 1224 1225 1226 1227 1228 1230 1231 1232 1234 1235 1237 1238 1240 1242 1243 1245 1248 1249 1250 1251 1252 1254 1256 1257 1258 1259 1260 1261 1262 1263 1264 1266 1267 1268 1269 1271 1272 1274 1276 1277 1278 1279 1280 1282 1283 1284 1285 1286 1287 1289 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1307 1308 1309 1310 1311 1312 1314 1315 1316 1317 1318 1320 1321 1322 1324 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1337 1339 7.4. measures.xsd 1341 The following file is the profile version of "measures.xsd". 1343 1344 1349 1351 1352 1353 1354 1355 1356 1358 1359 1360 1361 1362 1363 1365 1367 7.5. gmlBase.xsd 1369 The following file is the profile version of "gmlBase.xsd". 1371 1372 1377 1379 1381 1383 1384 1385 1387 1388 1390 7.6. basicTypes.xsd 1392 The following file is the profile version of "basicTypes.xsd". 1394 1395 1400 1401 1402 1403 1404 1405 1407 1408 1409 1411 1412 1413 1415 1416 1417 1419 1420 1421 1423 1424 1425 1426 1427 1428 1429 1431 1432 1433 1435 1437 8. Security Considerations 1439 It is believed that this document does not have any security 1440 considerations. If this information is included within a PIDF-LO 1441 document, the security considerations of [RFC4119] apply, especially 1442 those that are related to privacy. 1444 9. IANA Considerations 1446 This section registers the application schema for geodetic shapes and 1447 its namespace with IANA. 1449 9.1. URN Sub-Namespace Registration for 1450 urn:ietf:params:xml:ns:pidf:geopriv10:geoShape 1452 This section registers a new XML namespace, 1453 "urn:ietf:params:xml:ns:pidf:geopriv10:geoShape", as per the 1454 guidelines in [RFC3688]. 1456 URI: urn:ietf:params:xml:ns:pidf:geopriv10:geoShape 1458 Registrant Contact: IETF, GEOPRIV working group, 1459 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1461 XML: 1463 BEGIN 1464 1465 1467 1468 1469 GEOPRIV GML Application Schema 1470 1471 1472

Namespace for GEOPRIV GML Application Schema

1473

urn:ietf:params:xml:ns:pidf:geopriv10:geoShape

1474 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1475 with the RFC number for this specification.]] 1476

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 . 1518 11.2. Informative References 1520 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1521 January 2004. 1523 [I-D.ietf-geopriv-revised-civic-lo] 1524 Thomson, M. and J. Winterbottom, "Revised Civic Location 1525 Format for PIDF-LO", 1526 draft-ietf-geopriv-revised-civic-lo-04 (work in progress), 1527 September 2006. 1529 [W3C.REC-xlink-20010627] 1530 DeRose, S., Orchard, D., and E. Maler, "XML Linking 1531 Language (XLink) Version 1.0", World Wide Web Consortium 1532 Recommendation REC-xlink-20010627, June 2001, 1533 . 1535 [NIMA.TR8350.2-3e] 1536 US National Imagery and Mapping Agency, "Department of 1537 Defense (DoD) World Geodetic System 1984 (WGS 84), Third 1538 Edition", NIMA TR8350.2, January 2000. 1540 [EPSG.GN7-2] 1541 European Petroleum Survey Group, "Coordinate Conversions 1542 and Transforms including Formulas", EPSG Guidance Note 7, 1543 part 2 , November 2005, 1544 . 1546 [3GPP.TS23032] 1547 3GPP, "Universal Geographical Area Description (GAD)", 1548 3GPP TS 23.032 v6.0.0, December 2004. 1550 [ISO.19757-3.2005] 1551 International Organization for Standardization and 1552 International Electrotechnical Commission, "Document 1553 Schema Definitions Languages (DSDL): Part 3 - Rule-based 1554 validation - Schematron", ISO/IEC FDIS 19757-3, 2005. 1556 [Sunday02] 1557 Sunday, D., "Fast polygon area and Newell normal 1558 computation.", Journal of Graphics Tools JGT, 7(2):9- 1559 13,2002, 2002, . 1561 Appendix A. Calculating the Upward Normal of a Polygon 1563 For a polygon that is guaranteed to be convex and coplanar, the 1564 upward normal can be found by finding the vector cross product of 1565 adjacent edges. 1567 For more general cases the Newell method of approximation described 1568 in [Sunday02] may be applied. In particular, this method can be used 1569 if the points are only approximately coplanar, and for non-convex 1570 polygons. 1572 This method can be condensed to the following set of equations: 1574 Ux := sum from i=1..n of (y[i] * (z[i+1] - z[i-1])) 1576 Uy := sum from i=1..n of (z[i] * (x[i+1] - x[i-1])) 1578 Uz := sum from i=1..n of (x[i] * (y[i+1] - y[i-1])) 1580 For these formulae, the polygon is made of points (x[1], y[1], z[1]) 1581 through (x[n], y[n], x[n]). Each array is treated as circular, that 1582 is, x[0] = x[n] and x[n+1] = x[1]. 1584 Note: This method assumes a cartesian coordinate system, this SHOULD 1585 NOT be applied to coordinates specified in the WGS 84 (latitude, 1586 longitude, altitude) CRS. Coordinates specified in a geographic CRS 1587 SHOULD be transformed to a cartesian, geocentric CRS (such as EPSG 1588 4978) before this method is applied, see [EPSG.GN7-2] and 1589 [NIMA.TR8350.2-3e] for details. 1591 Appendix B. Change Log 1593 [[The RFC Editor is requested to remove this section at 1594 publication.]] 1596 Changes since draft-thomson-geopriv-geo-shape-02: 1598 o Corrected typographical errors. 1600 Changes since -01: 1602 o Added more guidance on applicability. 1604 o Added more guidance on approximations methods and the limits to 1605 those methods. 1607 Changes since -00: 1609 o Removed 16 point limit on Polygons. 1611 o Resolved outstanding issues (no changes). 1613 Author's Address 1615 Martin Thomson 1616 Andrew 1617 PO Box U40 1618 Wollongong University Campus, NSW 2500 1619 AU 1621 Phone: +61 2 4221 2915 1622 Email: martin.thomson@andrew.com 1623 URI: http://www.andrew.com/ 1625 Full Copyright Statement 1627 Copyright (C) The IETF Trust (2006). 1629 This document is subject to the rights, licenses and restrictions 1630 contained in BCP 78, and except as set forth therein, the authors 1631 retain all their rights. 1633 This document and the information contained herein are provided on an 1634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1637 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1638 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1641 Intellectual Property 1643 The IETF takes no position regarding the validity or scope of any 1644 Intellectual Property Rights or other rights that might be claimed to 1645 pertain to the implementation or use of the technology described in 1646 this document or the extent to which any license under such rights 1647 might or might not be available; nor does it represent that it has 1648 made any independent effort to identify any such rights. Information 1649 on the procedures with respect to rights in RFC documents can be 1650 found in BCP 78 and BCP 79. 1652 Copies of IPR disclosures made to the IETF Secretariat and any 1653 assurances of licenses to be made available, or the result of an 1654 attempt made to obtain a general license or permission for the use of 1655 such proprietary rights by implementers or users of this 1656 specification can be obtained from the IETF on-line IPR repository at 1657 http://www.ietf.org/ipr. 1659 The IETF invites any interested party to bring to its attention any 1660 copyrights, patents or patent applications, or other proprietary 1661 rights that may cover technology that may be required to implement 1662 this standard. Please address the information to the IETF at 1663 ietf-ipr@ietf.org. 1665 Acknowledgment 1667 Funding for the RFC Editor function is provided by the IETF 1668 Administrative Support Activity (IASA).