GeoPriv R. Marshall Internet-Draft TCS Intended status: Informational R. George Expires: August 5, 2011 J. Polk TCS February 2011 A protocol for location transformations draft-marshall-geopriv-location-transform-00 Marshall, et al. Expires August 5, 2011 [Page 1] Internet-Draft General Location Transformation Protocol February 2011 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Marshall, et al. Expires August 5, 2011 [Page 2] Internet-Draft General Location Transformation Protocol February 2011 Abstract This document defines a general protocol useful for transforming location information between various formats for use by location relevant messaging elements and applications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 5, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Marshall, et al. Expires August 5, 2011 [Page 3] Internet-Draft General Location Transformation Protocol February 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Location Transformation . . . . . . . . . . . . . 7 4. Geographic Information Systems (GIS) . . . . . . . . . . . . . 8 5. Location Transformation Services . . . . . . . . . . . . . . . 9 6. Simple Location Transformation Protocol . . . . . . . . . . . 10 7. Discovering the Location Transformation Service . . . . . . . 11 8. Applications in Location Transformation . . . . . . . . . . . 12 8.1. Civic-to-Geodetic Location Transforms . . . . . . . . . . 12 8.2. Geodetic-to-Civic Location Transforms . . . . . . . . . . 12 8.3. Sample Coordinate Reference System Transformations . . . . 13 9. Location Messaging Profiles . . . . . . . . . . . . . . . . . 14 9.1. Geographic Location Profiles . . . . . . . . . . . . . . . 14 9.1.1. Two Dimensional Geographic Coordinate profile . . . . 14 9.1.2. 3-D Geographic Coordinate profile . . . . . . . . . . 14 9.2. Civic Location Profiles . . . . . . . . . . . . . . . . . 14 9.2.1. Street Address profile . . . . . . . . . . . . . . . . 14 9.2.2. USPS Address profile . . . . . . . . . . . . . . . . . 14 9.3. Hybrid Location Profiles . . . . . . . . . . . . . . . . . 14 9.3.1. 2-D Geographic Coordinates with Civic Address "floor" element . . . . . . . . . . . . . . . . . . . 14 9.4. Polygon (shape) Profiles . . . . . . . . . . . . . . . . . 14 9.4.1. Municipal (i.e., Parcel) boundary . . . . . . . . . . 14 9.4.2. standard geometric shapes . . . . . . . . . . . . . . 14 10. Output Resolution . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Geocoding Resolution . . . . . . . . . . . . . . . . . . . 16 10.1.1. Uncertainty and Confidence . . . . . . . . . . . . . . 16 10.2. Reverse Geocoding Resolution . . . . . . . . . . . . . . . 16 10.2.1. Matched-Point, Matched-Polygon, unmatched-interpolated, and unchecked address elements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Errors and Warnings . . . . . . . . . . . . . . . . . . . . . 17 11.1. Error messages . . . . . . . . . . . . . . . . . . . . . . 17 11.1.1. 4XX Bad Responses . . . . . . . . . . . . . . . . . . 17 11.1.2. 5XX Internal System Errors . . . . . . . . . . . . . . 17 11.2. Warning messages . . . . . . . . . . . . . . . . . . . . . 17 11.3. Informational messages . . . . . . . . . . . . . . . . . . 17 12. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 18 13. Considerations for International CRS support . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 17.1. Normative References . . . . . . . . . . . . . . . . . . . 23 17.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Marshall, et al. Expires August 5, 2011 [Page 4] Internet-Draft General Location Transformation Protocol February 2011 1. Introduction All location-based services rely on location information in one form or another. In the case where location information is available, but is not in a readily usable form, it must be transformed. Location transformation is more complicated than straightforward unit conversion, since location can be represented according to many different frames of reference. This document introduces a general method, or protocol, which can be implemented by client and server applications to transform location information between a variety of location forms and formats. It is conceivable that many kinds of applications could benefit from this mechanism, but are likely to be too numerous to describe here, and therefore, except for example purposes, are beyond the scope of this document. A section that provides a mechanism for the discovery of transformation services using the LoST protocol [RFC5222] is included. The structure of this document includes terminology, Section 2, followed by a discussion of the basic elements involved in location transformation. These elements, or actors, are discussed in an overview section, Section 3, accompanied by a graph, associated processing steps, and a brief discussion around the use, options, and message examples for a location transformation protocol. Marshall, et al. Expires August 5, 2011 [Page 5] Internet-Draft General Location Transformation Protocol February 2011 2. Terminology 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 RFC 2119 [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of the Location Configuration Protocol and the Location Dereferencing Protocol, not its implementation or application. The following terms are defined in this document: Transformation: Rendering one form of location information into another form. Location: Refering to Location information that is useful in the context of location-based applications. Geocoding: A process of transforming a civic style location into a geographic style of location. Reverse Geocoding: A process of transforming a geographic style of location into a civic style of location. Geographic location: A format of location information that is represented by geographic coordinates within a geographic coordinate system. Geodetic location: A replacement term for geographic location. Datum: A defined system of reference associated with the associated set of geographic location information. Marshall, et al. Expires August 5, 2011 [Page 6] Internet-Draft General Location Transformation Protocol February 2011 3. Overview of Location Transformation For location information to be usable, it must be represented in a form that makes sense to the person or application that receives it. In most cases, location information is in one of two common forms, civic location, and geographic, or "geodetic" location. Civic location, which has a datum that varies by country, or region, is most often thought of as a "street address". A civic location is often represented as the common address at which a person lives or works, or even just visits. An example of this might be the (example) address of "316 Hightower Street, Independence, Missouri, USA", which represents a house, apartment, or building number, along some named street or thoroughfare, within some village, town, or city, and belonging to particular state, province, and country. The notion of having a standard set of civic address elements may exist among some jurisdictions on Earth, though is not universally the case. Geodetic location, (in this document, we equate the term geodetic location with geographic location), represents a specific place on some kind of grid. As an example, one commonly used reference system standard, or "datum", is referred to as WGS84, and defines a global grid that can be used to locate a position anywhere on earth using a set of geodetic coordinates for latitude, longitude, and (optionally) altitude. Whereas most geodetic datums are more broadly defined to be a continental or globally applicable coordinate reference system, civic locations are defined locally, based on a specific preference, dictated by a municipality, region, county, state, or country. The transformation mechanism described here is not only for use in transforming location information from civic-to-geodetic, or geodetic-to-civic, but also between various civic, geo, and other representations. Marshall, et al. Expires August 5, 2011 [Page 7] Internet-Draft General Location Transformation Protocol February 2011 4. Geographic Information Systems (GIS) Geographic Information System (GIS) is software that is designed to enable applications that rely on location. GIS applications provide a mechanism to store, compare, manipulate, and report geographic information, incorporating many types of geodetic and civic location features and elements. GIS systems, once they are provisioned with location data, are useful in associating geodetic data with civic data. For example, given a lat/lon, a GIS application can be used to display the coordinate position on a geographic map display, and can be used to associate other geographic features, including a civic location in close proximity to the input set of coordinates. Marshall, et al. Expires August 5, 2011 [Page 8] Internet-Draft General Location Transformation Protocol February 2011 5. Location Transformation Services Location transformation services are intentioned to be able to support public, private, or commercial needs, and are envisioned to be made available via the Internet or through commercial network interconnections. Marshall, et al. Expires August 5, 2011 [Page 9] Internet-Draft General Location Transformation Protocol February 2011 6. Simple Location Transformation Protocol The transform element The crsType element The location element The runTime element The matched element The similar element The shape element Marshall, et al. Expires August 5, 2011 [Page 10] Internet-Draft General Location Transformation Protocol February 2011 7. Discovering the Location Transformation Service In order to process a location transformation, there must be a mechanism to discover such a service. The LoST [RFC5222] protocol does service discovery by using already supplied location, as well as Service URN that is specific to the service being requested. For this purpose, a new service URN, urn:service:transform is introduced. Since a LoST server is expected to contain both geodetic and civic data layer information, either form is supported in the input, along with the specific service urn. If the LoST server cannot successfully perform this transformation because the input location is outside it's internal data footprint, it is expected that a URI would be returned that would point the LoST client to a more location appropriate LoST server. Marshall, et al. Expires August 5, 2011 [Page 11] Internet-Draft General Location Transformation Protocol February 2011 8. Applications in Location Transformation 8.1. Civic-to-Geodetic Location Transforms Description Geocoding is the transformation of a civic address into a set of geodetic coordinates. Since the specific technique of conversion to these geodetic coordinates is implementation specific, this document only describes the interface over which a request/ response for a civic address is sought. Many forms of a civic address can be used as input, and the response can be provided according to a specified datum, or may be in accordance with a default datum if no input datum is requested, or the requested datum is unavailable. The common case for geocoding is to provide a civic street address and get back a lat/lon (2D example). This interface supports the return of polygon data sets as well as individual coordinates. It also supports specific shape types as well as point data. Examples USPS-Civic-to-Geo-Point USPS Street Address to WGS84 geographic coordinate pair MSAG-Civic-to-Geo-Polygon MSAG Street Address to Parcel polygon (multi-coordinate set) 8.2. Geodetic-to-Civic Location Transforms Description Reverse geocoding is the transformation from a set of geodetic coordinates to a representative civic location. Every commercial GIS software has its own unique algorithm that it uses to make this conversion. Because of this, it may be that no two vendors'geocoding operations result in the same output. The type of data used within the GIS also has an important impact on the expected results. Finite polygon data, for example, (often referred to as parcel polygons), that is loaded into a GIS will provide a much more sensible rendering of a civic address than would be produced by the datasets containing only point data (e.g., site structure) or street centerline data. As with geocoding, because this operation is implementation specific, this document only describes the interface protocol over which a request/response for a civic location is asked for. Since civic Marshall, et al. Expires August 5, 2011 [Page 12] Internet-Draft General Location Transformation Protocol February 2011 location can be represented in Various formats, both the request and response message sets will contain profile identifiers that describe which form of civic location was sought, as well as which type was returned (in case the requested type was unavailable). A Couple of Use Case Examples 2D-Geo-to-Postal Two dimensional geographic coordinates to USPS Street Address A transformation from a two-dimensional geodetic coordinate set to a USPS styled civic location in a form consistent with USPS Publication 28 guidlines. This case is when a lat/lon target destination is supplied by, lets say a personal navigation device, but no corresponding civic location is provided. 3D-Geo-to-Postal Three dimensional geographic coordinates to USPS Street Address This transformation is a variation of the above case, but bring in the ability to do transformations where elevation or altitude differentiates one civic location from another (e.g., hi-rise appartment building). 8.3. Sample Coordinate Reference System Transformations Potential Applications of Transformed Location Of the many Coordinate Reference Systems and published addressing standards currently in use, some of the more popular CRS' used in commercial and public safety contexts are as follows. NAD83-to-WGS84 NAD83 (North American Datum 1983) to WGS84 (World Geodetic Standard 1984) Geodetic transforms WGS84-to-NAD83 WGS84 to NAD83 Geodetic transforms MSAG-to-USPS MSAG to USPS Civic transforms Marshall, et al. Expires August 5, 2011 [Page 13] Internet-Draft General Location Transformation Protocol February 2011 9. Location Messaging Profiles A location message profile described here is an example of an xml representation of the each kind of request and response message and location profile specified within the messages. 9.1. Geographic Location Profiles 9.1.1. Two Dimensional Geographic Coordinate profile Example xml to be supplied] 9.1.2. 3-D Geographic Coordinate profile Example xml to be supplied] 9.2. Civic Location Profiles 9.2.1. Street Address profile Example xml to be supplied] 9.2.2. USPS Address profile Example xml to be supplied] 9.3. Hybrid Location Profiles 9.3.1. 2-D Geographic Coordinates with Civic Address "floor" element Example xml to be supplied] 9.4. Polygon (shape) Profiles 9.4.1. Municipal (i.e., Parcel) boundary Example xml to be supplied] 9.4.2. standard geometric shapes Examples of xml for each of the following to be supplied] point: circle: Marshall, et al. Expires August 5, 2011 [Page 14] Internet-Draft General Location Transformation Protocol February 2011 ellipse: ellipsoid: sphere: arc band: Marshall, et al. Expires August 5, 2011 [Page 15] Internet-Draft General Location Transformation Protocol February 2011 10. Output Resolution Along with the actual location information, additional qualifying information is also necessary, depending on the type of location used 10.1. Geocoding Resolution 10.1.1. Uncertainty and Confidence For any geodetic point shape that is measured directly, or in this case, derived as a result of a transformation operation, there must be included with the result, additional qualifying information, such as the point's resolution, essentially a tolerance, or the amount of probable error, and the estimated probability of that resolution/ error. 10.2. Reverse Geocoding Resolution For any civic address that is returned from a reverse geocoding operation, it may be advantageous to know which elements of the civic location that was returned were found in the GIS data layer. Some of these data may be matched in the internal data structure 10.2.1. Matched-Point, Matched-Polygon, unmatched-interpolated, and unchecked address elements to be supplied] Marshall, et al. Expires August 5, 2011 [Page 16] Internet-Draft General Location Transformation Protocol February 2011 11. Errors and Warnings 11.1. Error messages 11.1.1. 4XX Bad Responses to be supplied] 11.1.2. 5XX Internal System Errors to be supplied] 11.2. Warning messages to be supplied] 11.3. Informational messages Matched element response Element not matched response Unused element response Marshall, et al. Expires August 5, 2011 [Page 17] Internet-Draft General Location Transformation Protocol February 2011 12. Relax NG schema [This section to be supplied] Marshall, et al. Expires August 5, 2011 [Page 18] Internet-Draft General Location Transformation Protocol February 2011 13. Considerations for International CRS support Civic Address Profile definitions [This section to be supplied] Geographic CRS definitions [This section to be supplied] Marshall, et al. Expires August 5, 2011 [Page 19] Internet-Draft General Location Transformation Protocol February 2011 14. Security Considerations [This section to be supplied] Marshall, et al. Expires August 5, 2011 [Page 20] Internet-Draft General Location Transformation Protocol February 2011 15. IANA Considerations [This section to be supplied] Marshall, et al. Expires August 5, 2011 [Page 21] Internet-Draft General Location Transformation Protocol February 2011 16. Acknowledgements [This section to be supplied] Marshall, et al. Expires August 5, 2011 [Page 22] Internet-Draft General Location Transformation Protocol February 2011 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 17.2. Informative References Marshall, et al. Expires August 5, 2011 [Page 23] Internet-Draft General Location Transformation Protocol February 2011 Authors' Addresses Roger Marshall TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US Phone: +1 206 792 2424 Email: rmarshall@telecomsys.com URI: http://www.telecomsys.com Robins George A Phone: Email: robinsgv@gmail.com URI: James Polk Cisco Systems 3913 Treemont Circle 2nd Floor Colleyville, Texas 76034 US Phone: +1-817-271-3552 Email: jmpolk@cisco.com URI: http://www.cisco.com Marshall, et al. Expires August 5, 2011 [Page 24]