[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]