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]