GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group enum.at
Internet-Draft C. Spanring
Expires: November 22, 2008 OIR-ID
May 21, 2008
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-mayrhofer-geopriv-geo-uri-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 22, 2008.
Abstract
This document specifies an Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI
provides latitude, longitude and optionally altitude of a physical
location in a compact, simple, human-readable, and protocol
independent way.
Mayrhofer & Spanring Expires November 22, 2008 [Page 1]
Internet-Draft 'geo' URI scheme May 2008
Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 5
4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 5
4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 5
4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6
4.4.1. Component Description . . . . . . . . . . . . . . . . 6
4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 6
4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 7
4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 7
4.6. Applications/protocols That Use This URI Scheme . . . . . 7
4.7. Interopability Considerations . . . . . . . . . . . . . . 7
4.8. Security Considerations . . . . . . . . . . . . . . . . . 7
4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.10. Author/Change controller . . . . . . . . . . . . . . . . . 8
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Use of 'geo' URIs . . . . . . . . . . . . . . . . . . . . . . 8
5.1. URI Operations . . . . . . . . . . . . . . . . . . . . . . 8
6. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 8
6.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 9
6.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 9
6.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 10
7. Examples and Use Cases . . . . . . . . . . . . . . . . . . . . 10
7.1. Plain 'geo' URI . . . . . . . . . . . . . . . . . . . . . 10
7.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 11
9.2. Location Privcay . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Mayrhofer & Spanring Expires November 22, 2008 [Page 2]
Internet-Draft 'geo' URI scheme May 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Mayrhofer & Spanring Expires November 22, 2008 [Page 3]
Internet-Draft 'geo' URI scheme May 2008
1. Change Log
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-mayrhofer-geopriv-geo-uri-00
o Initial version under new name, reverting to "plain" lat/lon
scheme, with the "tiling" scheme moved to seperate draft
(potentially published as "draft-mayrhofer-geopriv-geotile-uri").
refer to draft-mayrhofer-geo-uri-01 for the history of this
document.
o Added GML mapping section
draft-mayrhofer-geo-uri-01
o removed parameters
draft-mayrhofer-geo-uri-00
o initial draft
2. Introduction
An increasing number of Internet protocols and data formats are being
enriched by specifications on how to add information about geographic
location to them. In most cases, latitude as well as longitude are
added as attributes to existing data structures. However, all those
methods are specific to a certain data format or protocol, and don't
provide a generic way to protocol independent location
identification.
Over the past few years, fast emerging location aware applications
and location based services were observable on the Internet. Most
web search engines use geographic information, and a vivid open
source mapping community brought an enormous momentum into location
aware technology. A wide range and former to professionals exclusive
tools and data were provided free of charge for an everyday use on
the mass market.
The 'geo' URI scheme is another step into that direction and aims to
facilitate, support and standardize the problem of location
identification in geospatial services and applications. Accessing
information about or trigger further services based on a particular
place on earth shouldn't be any harder for users than clicking on a
'mailto:' link and write an email straight away.
According to [RFC3986], a Uniform Resource Identifier (URI) is "a
compact sequence of characters that identifies an abstract or
physical resource". The 'geo' URI scheme defined in this document
Mayrhofer & Spanring Expires November 22, 2008 [Page 4]
Internet-Draft 'geo' URI scheme May 2008
identifies geographic locations (a physical resource) in the WGS84
[WGS84] reference system.
'Geo' URIs identify a geographic location using a textual
representation of the location's spatial coordinates in either two or
three dimensions (latitude, longitude, and optionally altitude).
Such URIs are independent from a specific protocol, application, or
data format in which they might be contained.
The provision of civic addresses to identify locations is out of
scope of this document.
Note: The choice of WGS84 is based on the widespread availability of
Global Positioning System (GPS) devices, which use the WGS84
reference system. It is anticipated that such devices serve as one
of the primary data sources for authoring 'geo' URIs, hence the
adoption of the native GPS reference system for the URI scheme.
3. 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].
4. IANA Registration of 'geo' URI Scheme
This section contains the fields required for the URI scheme
registration, following the guidelines in section 5.4 of [RFC4395].
4.1. URI Scheme Name
geo
4.2. Status
permanent
4.3. URI Scheme Syntax
The syntax of the 'geo' URI scheme is specified below in Augmented
Backus-Naur Form (ABNF) [RFC4234]:
Mayrhofer & Spanring Expires November 22, 2008 [Page 5]
Internet-Draft 'geo' URI scheme May 2008
geo-URI = geo-scheme ":" geo-path
geo-scheme = "geo"
geo-path = geo-location
geo-location = latitude "," longitude [ "," altitude ]
latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ]
altitude = [ "-" ] *DIGIT [ "." *DIGIT ]
4.4. URI Scheme Semantics
Generally, data contained in a 'geo' URI identifies a physical
resource: A spatial location on earth identified by the geographic
coordinates contained in the URI.
4.4.1. Component Description
The "latitude", "longitude" and "altitude" components as specified in
the URI scheme syntax ( Section 4.3) are to be used as follows:
o The "latitude" component MUST contain the decimal latitude of the
identified location in the reference system WGS 84.
o The "longitude" componont MUST contain the decimal longitude of
the identified location in the reference system WGS 84.
o If present, the OPTIONAL "altitude" component MUST contain the
WGS84 decimal altitude of the identified location in meters
(elevation above mean sea level).
If the altitude of the location is unknown, the "altitude" component
MUST NOT be present in the URI. Specifically, unknown altitude MUST
NOT be represented by setting the 'altitude' component to "0" (or any
other arbitrary value).
The number of decimal places indicates the precision of the value.
One degree equals 111.319,45m at the equator (40.075,004km / 360
degree). Five decimal places (0.00001 degree) seem to imply a for
civil use sufficient accuracy.
4.4.2. URI Comparison
Two 'geo' URIs MUST be considered equal when their 'longitude',
'latitude' and 'altitude' values are mathematically identical.
An URI with undefined (missing) 'altitude' value MUST NOT be
considered identical to an URI with an 'altitude' value, even if the
remaining components 'latitude', and 'longitude' match.
Mayrhofer & Spanring Expires November 22, 2008 [Page 6]
Internet-Draft 'geo' URI scheme May 2008
4.4.3. Interpretation of Undefined Altitude
A consumer of an 'geo' URI with undefined 'altitude' MAY assume that
the URI refers to the location on earth's surface at the given
'latitude' and 'longitude' coordinate.
4.5. Encoding Considerations
The 'geo-location' path component of the 'geo' URI (see Section 4.3)
uses a comma (",") as a delimiter for subcomponents. This delimiter
MUST NOT be percent encoded.
It is RECOMMENDED that for readability the contents of 'latitude',
'longitude' and 'altitude' subcomponents are never percent encoded.
4.6. Applications/protocols That Use This URI Scheme
The 'geo' URI provides resource identification independent of a
specific application or protocol. Examples of potential protocol
mappings and use cases can be found in Section 7.
4.7. Interopability Considerations
As with any other new URI scheme, the 'geo' URI requires support in
client applications. Users of applications which are not aware of
the 'geo' scheme are likely unable to make use of the information in
the URI (unless they dereference the URI components manually).
Poorly authored 'geo' URI instances could contain whitespace.
Clients SHOULD try to dereference such URIs after removing
whitespace.
This specification does not define any URI parameters nor a query
component. Future revisions might define such parameters,
potentially using the ";" and "?" characters to delimit parameter and
query components from the path component. Clients SHOULD be prepared
to encounter such 'geo' instances, and SHOULD reduce the URI to the
components specified in Section 4.3 before they dereference the URI.
4.8. Security Considerations
See Section 9 of [insert reference to this document]
4.9. Contact
Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/),
Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at,
http://nona.net/)
Mayrhofer & Spanring Expires November 22, 2008 [Page 7]
Internet-Draft 'geo' URI scheme May 2008
4.10. Author/Change controller
The 'geo' URI scheme is registered under the IETF part of the URI
tree. As such, change control is up to the IETF.
4.11. References
RFC XXXX [change to RFC number once assigned]
5. Use of 'geo' URIs
5.1. URI Operations
Currently, just one operation on a 'geo' URI is defined - location
dereference: In that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component.
Further use of those coordinates is then up to the application
processing the URI.
An application may then use this location information for various
purposes, for example:
A web browser could that information into the URI of a web mapping
service of the user's choice, and display a map of the location
A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location.
6. GML Mappings
A 'geo' URI can be authored from a GML "point", and any 'geo' URI can
be mapped to a GML "point". For the following sections, For the
following sections, "%lat%", "%lon%" and "%alt%" are to be considered
placeholders for latitude, longitude, and altitude values. Mappings
are defined as follows:
6.1. 'geo' URI without altitude to GML 'Point'
An instance of the 'geo' URI without the altitude element is mapped
to a two-dimensional GML "Point" as follows:
'geo' URI:
geo:%lat%,%lon%
GML document:
Mayrhofer & Spanring Expires November 22, 2008 [Page 8]
Internet-Draft 'geo' URI scheme May 2008
one of Vienna's popular sights is the Karlskirche
A web brower could extract the coordinates from the HTML snippet, and
offer the user various options (based on configuration, context), for
example:
Mayrhofer & Spanring Expires November 22, 2008 [Page 10]
Internet-Draft 'geo' URI scheme May 2008
o display a small map when the mouse pointer hovers over the link
o switch to a mapping service of the user's choice once the link is
selected
o Locate nearby resources, for example by making use of GeoRSS feeds
the user has subscribed to
o Convert the coordinates to a format suitable for uploading to a
navigation device
8. IANA Considerations
This document requests assignment of the 'geo' URI scheme in the IETF
part of the URI scheme tree, according to the guidelines in BCP 115
(RFC 4395) [RFC4395]. The definitions required for the assignment
are contained in Section 4.
9. Security Considerations
Because the 'geo' URI is not tied to any specific protocol, and
identifies a physical location rather than a network resource, most
of the general security considerations on URIs (Section 7 of RFC
3986) do not apply. However, the following (additional) issues
apply:
9.1. Invalid Locations
The URI syntax (Section 4.3) makes it possible to construct valid
'geo' URIs which don't identify a valid location on earth.
Applications MUST NOT use URIs which such invalid values, and SHOULD
warn the user when such URIs are encountered.
An example of such an invalid URI would be