idnits 2.17.00 (12 Aug 2021) /tmp/idnits41611/draft-marshall-geopriv-location-transform-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2011) is 4106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5222' is mentioned on line 249, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall 3 Internet-Draft TCS 4 Intended status: Informational R. George 5 Expires: August 5, 2011 6 J. Polk 7 TCS 8 February 2011 10 A protocol for location transformations 11 draft-marshall-geopriv-location-transform-00 13 This document may contain material from IETF Documents or IETF 14 Contributions published or made publicly available before November 15 10, 2008. The person(s) controlling the copyright in some of this 16 material may not have granted the IETF Trust the right to allow 17 modifications of such material outside the IETF Standards Process. 18 Without obtaining an adequate license from the person(s) controlling 19 the copyright in such materials, this document may not be modified 20 outside the IETF Standards Process, and derivative works of it may 21 not be created outside the IETF Standards Process, except to format 22 it for publication as an RFC or to translate it into languages other 23 than English. 25 Abstract 27 This document defines a general protocol useful for transforming 28 location information between various formats for use by location 29 relevant messaging elements and applications. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 5, 2011. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Overview of Location Transformation . . . . . . . . . . . . . 7 68 4. Geographic Information Systems (GIS) . . . . . . . . . . . . . 8 69 5. Location Transformation Services . . . . . . . . . . . . . . . 9 70 6. Simple Location Transformation Protocol . . . . . . . . . . . 10 71 7. Discovering the Location Transformation Service . . . . . . . 11 72 8. Applications in Location Transformation . . . . . . . . . . . 12 73 8.1. Civic-to-Geodetic Location Transforms . . . . . . . . . . 12 74 8.2. Geodetic-to-Civic Location Transforms . . . . . . . . . . 12 75 8.3. Sample Coordinate Reference System Transformations . . . . 13 76 9. Location Messaging Profiles . . . . . . . . . . . . . . . . . 14 77 9.1. Geographic Location Profiles . . . . . . . . . . . . . . . 14 78 9.1.1. Two Dimensional Geographic Coordinate profile . . . . 14 79 9.1.2. 3-D Geographic Coordinate profile . . . . . . . . . . 14 80 9.2. Civic Location Profiles . . . . . . . . . . . . . . . . . 14 81 9.2.1. Street Address profile . . . . . . . . . . . . . . . . 14 82 9.2.2. USPS Address profile . . . . . . . . . . . . . . . . . 14 83 9.3. Hybrid Location Profiles . . . . . . . . . . . . . . . . . 14 84 9.3.1. 2-D Geographic Coordinates with Civic Address 85 "floor" element . . . . . . . . . . . . . . . . . . . 14 86 9.4. Polygon (shape) Profiles . . . . . . . . . . . . . . . . . 14 87 9.4.1. Municipal (i.e., Parcel) boundary . . . . . . . . . . 14 88 9.4.2. standard geometric shapes . . . . . . . . . . . . . . 14 89 10. Output Resolution . . . . . . . . . . . . . . . . . . . . . . 16 90 10.1. Geocoding Resolution . . . . . . . . . . . . . . . . . . . 16 91 10.1.1. Uncertainty and Confidence . . . . . . . . . . . . . . 16 92 10.2. Reverse Geocoding Resolution . . . . . . . . . . . . . . . 16 93 10.2.1. Matched-Point, Matched-Polygon, 94 unmatched-interpolated, and unchecked address 95 elements . . . . . . . . . . . . . . . . . . . . . . . 16 96 11. Errors and Warnings . . . . . . . . . . . . . . . . . . . . . 17 97 11.1. Error messages . . . . . . . . . . . . . . . . . . . . . . 17 98 11.1.1. 4XX Bad Responses . . . . . . . . . . . . . . . . . . 17 99 11.1.2. 5XX Internal System Errors . . . . . . . . . . . . . . 17 100 11.2. Warning messages . . . . . . . . . . . . . . . . . . . . . 17 101 11.3. Informational messages . . . . . . . . . . . . . . . . . . 17 102 12. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 18 103 13. Considerations for International CRS support . . . . . . . . . 19 104 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 105 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 106 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 107 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 17.1. Normative References . . . . . . . . . . . . . . . . . . . 23 109 17.2. Informative References . . . . . . . . . . . . . . . . . . 23 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 All location-based services rely on location information in one form 115 or another. In the case where location information is available, but 116 is not in a readily usable form, it must be transformed. Location 117 transformation is more complicated than straightforward unit 118 conversion, since location can be represented according to many 119 different frames of reference. 121 This document introduces a general method, or protocol, which can be 122 implemented by client and server applications to transform location 123 information between a variety of location forms and formats. It is 124 conceivable that many kinds of applications could benefit from this 125 mechanism, but are likely to be too numerous to describe here, and 126 therefore, except for example purposes, are beyond the scope of this 127 document. 129 A section that provides a mechanism for the discovery of 130 transformation services using the LoST protocol [RFC5222] is 131 included. 133 The structure of this document includes terminology, Section 2, 134 followed by a discussion of the basic elements involved in location 135 transformation. These elements, or actors, are discussed in an 136 overview section, Section 3, accompanied by a graph, associated 137 processing steps, and a brief discussion around the use, options, and 138 message examples for a location transformation protocol. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119], 145 with the important qualification that, unless otherwise stated, these 146 terms apply to the design of the Location Configuration Protocol and 147 the Location Dereferencing Protocol, not its implementation or 148 application. 150 The following terms are defined in this document: 152 Transformation: Rendering one form of location information into 153 another form. 155 Location: Refering to Location information that is useful in the 156 context of location-based applications. 158 Geocoding: A process of transforming a civic style location into a 159 geographic style of location. 161 Reverse Geocoding: A process of transforming a geographic style of 162 location into a civic style of location. 164 Geographic location: A format of location information that is 165 represented by geographic coordinates within a geographic 166 coordinate system. 168 Geodetic location: A replacement term for geographic location. 170 Datum: A defined system of reference associated with the associated 171 set of geographic location information. 173 3. Overview of Location Transformation 175 For location information to be usable, it must be represented in a 176 form that makes sense to the person or application that receives it. 177 In most cases, location information is in one of two common forms, 178 civic location, and geographic, or "geodetic" location. 180 Civic location, which has a datum that varies by country, or region, 181 is most often thought of as a "street address". A civic location is 182 often represented as the common address at which a person lives or 183 works, or even just visits. An example of this might be the 184 (example) address of "316 Hightower Street, Independence, Missouri, 185 USA", which represents a house, apartment, or building number, along 186 some named street or thoroughfare, within some village, town, or 187 city, and belonging to particular state, province, and country. The 188 notion of having a standard set of civic address elements may exist 189 among some jurisdictions on Earth, though is not universally the 190 case. 192 Geodetic location, (in this document, we equate the term geodetic 193 location with geographic location), represents a specific place on 194 some kind of grid. As an example, one commonly used reference system 195 standard, or "datum", is referred to as WGS84, and defines a global 196 grid that can be used to locate a position anywhere on earth using a 197 set of geodetic coordinates for latitude, longitude, and (optionally) 198 altitude. 200 Whereas most geodetic datums are more broadly defined to be a 201 continental or globally applicable coordinate reference system, civic 202 locations are defined locally, based on a specific preference, 203 dictated by a municipality, region, county, state, or country. 205 The transformation mechanism described here is not only for use in 206 transforming location information from civic-to-geodetic, or 207 geodetic-to-civic, but also between various civic, geo, and other 208 representations. 210 4. Geographic Information Systems (GIS) 212 Geographic Information System (GIS) is software that is designed to 213 enable applications that rely on location. GIS applications provide 214 a mechanism to store, compare, manipulate, and report geographic 215 information, incorporating many types of geodetic and civic location 216 features and elements. GIS systems, once they are provisioned with 217 location data, are useful in associating geodetic data with civic 218 data. For example, given a lat/lon, a GIS application can be used to 219 display the coordinate position on a geographic map display, and can 220 be used to associate other geographic features, including a civic 221 location in close proximity to the input set of coordinates. 223 5. Location Transformation Services 225 Location transformation services are intentioned to be able to 226 support public, private, or commercial needs, and are envisioned to 227 be made available via the Internet or through commercial network 228 interconnections. 230 6. Simple Location Transformation Protocol 232 The transform element 234 The crsType element 236 The location element 238 The runTime element 240 The matched element 242 The similar element 244 The shape element 246 7. Discovering the Location Transformation Service 248 In order to process a location transformation, there must be a 249 mechanism to discover such a service. The LoST [RFC5222] protocol 250 does service discovery by using already supplied location, as well as 251 Service URN that is specific to the service being requested. 253 For this purpose, a new service URN, urn:service:transform is 254 introduced. Since a LoST server is expected to contain both geodetic 255 and civic data layer information, either form is supported in the 256 input, along with the specific service urn. 258 If the LoST server cannot successfully perform this transformation 259 because the input location is outside it's internal data footprint, 260 it is expected that a URI would be returned that would point the LoST 261 client to a more location appropriate LoST server. 263 8. Applications in Location Transformation 265 8.1. Civic-to-Geodetic Location Transforms 267 Description 269 Geocoding is the transformation of a civic address into a set of 270 geodetic coordinates. Since the specific technique of conversion 271 to these geodetic coordinates is implementation specific, this 272 document only describes the interface over which a request/ 273 response for a civic address is sought. Many forms of a civic 274 address can be used as input, and the response can be provided 275 according to a specified datum, or may be in accordance with a 276 default datum if no input datum is requested, or the requested 277 datum is unavailable. The common case for geocoding is to provide 278 a civic street address and get back a lat/lon (2D example). This 279 interface supports the return of polygon data sets as well as 280 individual coordinates. It also supports specific shape types as 281 well as point data. 283 Examples 285 USPS-Civic-to-Geo-Point USPS Street Address to WGS84 geographic 286 coordinate pair 288 MSAG-Civic-to-Geo-Polygon MSAG Street Address to Parcel polygon 289 (multi-coordinate set) 291 8.2. Geodetic-to-Civic Location Transforms 293 Description 295 Reverse geocoding is the transformation from a set of geodetic 296 coordinates to a representative civic location. Every commercial 297 GIS software has its own unique algorithm that it uses to make 298 this conversion. Because of this, it may be that no two 299 vendors'geocoding operations result in the same output. The type 300 of data used within the GIS also has an important impact on the 301 expected results. Finite polygon data, for example, (often 302 referred to as parcel polygons), that is loaded into a GIS will 303 provide a much more sensible rendering of a civic address than 304 would be produced by the datasets containing only point data 305 (e.g., site structure) or street centerline data. As with 306 geocoding, because this operation is implementation specific, this 307 document only describes the interface protocol over which a 308 request/response for a civic location is asked for. Since civic 309 location can be represented in Various formats, both the request 310 and response message sets will contain profile identifiers that 311 describe which form of civic location was sought, as well as which 312 type was returned (in case the requested type was unavailable). 314 A Couple of Use Case Examples 316 2D-Geo-to-Postal Two dimensional geographic coordinates to USPS 317 Street Address 319 A transformation from a two-dimensional geodetic coordinate set 320 to a USPS styled civic location in a form consistent with USPS 321 Publication 28 guidlines. This case is when a lat/lon target 322 destination is supplied by, lets say a personal navigation 323 device, but no corresponding civic location is provided. 325 3D-Geo-to-Postal Three dimensional geographic coordinates to USPS 326 Street Address 328 This transformation is a variation of the above case, but bring 329 in the ability to do transformations where elevation or 330 altitude differentiates one civic location from another (e.g., 331 hi-rise appartment building). 333 8.3. Sample Coordinate Reference System Transformations 335 Potential Applications of Transformed Location 337 Of the many Coordinate Reference Systems and published addressing 338 standards currently in use, some of the more popular CRS' used in 339 commercial and public safety contexts are as follows. 341 NAD83-to-WGS84 NAD83 (North American Datum 1983) to WGS84 (World 342 Geodetic Standard 1984) Geodetic transforms 344 WGS84-to-NAD83 WGS84 to NAD83 Geodetic transforms 346 MSAG-to-USPS MSAG to USPS Civic transforms 348 9. Location Messaging Profiles 350 A location message profile described here is an example of an xml 351 representation of the each kind of request and response message and 352 location profile specified within the messages. 354 9.1. Geographic Location Profiles 356 9.1.1. Two Dimensional Geographic Coordinate profile 358 Example xml to be supplied] 360 9.1.2. 3-D Geographic Coordinate profile 362 Example xml to be supplied] 364 9.2. Civic Location Profiles 366 9.2.1. Street Address profile 368 Example xml to be supplied] 370 9.2.2. USPS Address profile 372 Example xml to be supplied] 374 9.3. Hybrid Location Profiles 376 9.3.1. 2-D Geographic Coordinates with Civic Address "floor" element 378 Example xml to be supplied] 380 9.4. Polygon (shape) Profiles 382 9.4.1. Municipal (i.e., Parcel) boundary 384 Example xml to be supplied] 386 9.4.2. standard geometric shapes 388 Examples of xml for each of the following to be supplied] 390 point: 392 circle: 394 ellipse: 396 ellipsoid: 398 sphere: 400 arc band: 402 10. Output Resolution 404 Along with the actual location information, additional qualifying 405 information is also necessary, depending on the type of location used 407 10.1. Geocoding Resolution 409 10.1.1. Uncertainty and Confidence 411 For any geodetic point shape that is measured directly, or in this 412 case, derived as a result of a transformation operation, there must 413 be included with the result, additional qualifying information, such 414 as the point's resolution, essentially a tolerance, or the amount of 415 probable error, and the estimated probability of that resolution/ 416 error. 418 10.2. Reverse Geocoding Resolution 420 For any civic address that is returned from a reverse geocoding 421 operation, it may be advantageous to know which elements of the civic 422 location that was returned were found in the GIS data layer. Some of 423 these data may be matched in the internal data structure 425 10.2.1. Matched-Point, Matched-Polygon, unmatched-interpolated, and 426 unchecked address elements 428 to be supplied] 430 11. Errors and Warnings 432 11.1. Error messages 434 11.1.1. 4XX Bad Responses 436 to be supplied] 438 11.1.2. 5XX Internal System Errors 440 to be supplied] 442 11.2. Warning messages 444 to be supplied] 446 11.3. Informational messages 448 Matched element response 450 Element not matched response 452 Unused element response 454 12. Relax NG schema 456 [This section to be supplied] 458 13. Considerations for International CRS support 460 Civic Address Profile definitions 462 [This section to be supplied] 464 Geographic CRS definitions 466 [This section to be supplied] 468 14. Security Considerations 470 [This section to be supplied] 472 15. IANA Considerations 474 [This section to be supplied] 476 16. Acknowledgements 478 [This section to be supplied] 480 17. References 482 17.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 17.2. Informative References 488 Authors' Addresses 490 Roger Marshall 491 TeleCommunication Systems, Inc. 492 2401 Elliott Avenue 493 2nd Floor 494 Seattle, WA 98121 495 US 497 Phone: +1 206 792 2424 498 Email: rmarshall@telecomsys.com 499 URI: http://www.telecomsys.com 501 Robins George 502 A 504 Phone: 505 Email: robinsgv@gmail.com 506 URI: 508 James Polk 509 Cisco Systems 510 3913 Treemont Circle 511 2nd Floor 512 Colleyville, Texas 76034 513 US 515 Phone: +1-817-271-3552 516 Email: jmpolk@cisco.com 517 URI: http://www.cisco.com