[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02
Network Working Group A. Mayrhofer
Internet-Draft enum.at
Expires: July 6, 2007 C. Spanring
OIR-ID
January 02, 2007
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-mayrhofer-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 July 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 location in
a simple, human-readable form. The 'geo' URI is not tied to a
specific application or protocol.
Mayrhofer & Spanring Expires July 6, 2007 [Page 1]
Internet-Draft 'geo' URI scheme January 2007
Table of Contents
1. Changes & Supplemental Information . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Registration of the 'geo' URI Scheme . . . . . . . . . . 4
4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 4
4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4
4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 4
4.4.1. Component Description . . . . . . . . . . . . . . . . 5
4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 5
4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 5
4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 5
4.6. Applications/protocols That Use This URI Scheme . . . . . 6
4.7. Interopability Considerations . . . . . . . . . . . . . . 6
4.8. Security Considerations . . . . . . . . . . . . . . . . . 6
4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.10. Author/Change controller . . . . . . . . . . . . . . . . . 6
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Use of 'geo' URIs . . . . . . . . . . . . . . . . . . . . . . 6
5.1. URI Construction . . . . . . . . . . . . . . . . . . . . . 6
5.2. URI Dereference . . . . . . . . . . . . . . . . . . . . . 8
5.3. URI Operations . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples and Use Cases . . . . . . . . . . . . . . . . . . . . 9
6.1. Plain 'geo' URI . . . . . . . . . . . . . . . . . . . . . 9
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Header Field . . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Web Mapping Services . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 11
8.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 11
8.3. Malicious Locations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Mayrhofer & Spanring Expires July 6, 2007 [Page 2]
Internet-Draft 'geo' URI scheme January 2007
1. Changes & Supplemental Information
[Note to editors: This section is to be removed before publication -
XML source available on request]
o draft-mayrhofer-geo-uri-00
* initial draft
A supplemental web site for the development of this draft and the
'geo' URI in general has been set up at <http://geouri.org/>
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 application, data format or
protocol, and don't provide a generic way to protocol independent
location identification.
Over the past few years, emerging location aware applications and
location based services were observable on the Internet. Most
Internet search engines and a vivid open source mapping community
brought an enormous momentum into location aware technology. A wide
range of tools and data formerly available to professionals only were
provided free of charge for everyday use on the mass market.
The 'geo' Uniform Resorce Identifier (URI) [1] scheme is another step
into that direction and aims to facilitate, support and standardize
part of the interaction with geospatial services and applications.
Accessing information about or trigger further services based on a
particular place on earth shouldn't be any harder than writing an
email by clicking on a 'mailto:' link.
A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
document specifies the 'geo' URI scheme for identifying geographic
locations in the WGS84 [5] reference system, independent of any
specific application, data format or protocol.
'Geo' URIs identify a geographic location by the textual
representation of the location's spatial coordinates in either two or
3 dimensions (latitude, longitude, and optionally altitude). An
optional query string contains additional parameters.
The provision of civic addresses (street, city, country, etc.) to
identify locations is out of scope for the 'geo' URI scheme.
Mayrhofer & Spanring Expires July 6, 2007 [Page 3]
Internet-Draft 'geo' URI scheme January 2007
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 [2].
4. IANA Registration of the 'geo' URI Scheme
This section contains information required for the URI scheme
registration, following the guidelines in section 5.4 of RFC 4395
[4].
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) [3]:
geo-URI = geo-scheme ":" geo-path [ "?" geo-query ]
geo-scheme = "geo"
geo-path = geo-location
geo-query = query
geo-location = latitude "," longitude [ "," altitude ]
latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ]
altitude = [ "-" ] *DIGIT [ "." *DIGIT ]
The 'query' component is specified in secion 3.4 of RFC 3986.
4.4. URI Scheme Semantics
Generally, data contained in a 'geo' URI describes the geographic
coordinates of the identified location, and contains an optional
query string.
Note: In order to achieve high user acceptance it seems inevitable to
adopt commonly known GPS parameters (latitude, longitude, altitude)
where possible.
Mayrhofer & Spanring Expires July 6, 2007 [Page 4]
Internet-Draft 'geo' URI scheme January 2007
4.4.1. Component Description
The "latitude", "longitude", "altitude" and "query" 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 WGS84.
o The "longitude" componont MUST contain the decimal longitude of
the identified location in the reference system WGS84.
o If present, the OPTIONAL "altitude" component MUST contain the
WGS84 decimal altitude of the identified location in meters
(elevation above mean seal 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.
As one degree equals 111319.45m at the equator (40075.004km / 360
degrees), five decimal places (0.00001 degree) correspond to roughly
one meter, which seem to provide sufficient accuracy for civil use.
4.4.2. URI Comparison
Two 'geo' URIs MUST be considered equal when their 'longitude',
'latitude' and 'altitude' values are mathematically identical, and
their decoded 'query' strings match.
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', 'longitude' and 'query' match.
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.
Mayrhofer & Spanring Expires July 6, 2007 [Page 5]
Internet-Draft 'geo' URI scheme January 2007
Contents of the 'query' component is to be encoded according to RFC
3986.
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 6.
4.7. Interopability Considerations
While the interpretation of 'latitude', 'longitude' and 'altitude' is
quite clear, the interpretation of the 'query' component may vary by
application or protocol to which a 'geo' URI is being mapped.
Consumers MUST ignore unknown query parameters they encounter while
authors of 'geo' URIs SHOULD only use well known parameters in the
'query' component.
To reduce interopability issues, it might be neccessary to create a
registry of query parameters.
4.8. Security Considerations
See Section 8 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/)
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
The 'geo' URI is specified in [insert reference to this document].
5. Use of 'geo' URIs
5.1. URI Construction
The production of a 'geo' URI involves the following steps:
Mayrhofer & Spanring Expires July 6, 2007 [Page 6]
Internet-Draft 'geo' URI scheme January 2007
1. Aquire coordinates of the location to be identified: latitude,
longitude, and optionally altitude.
2. If coordinates are given in degrees/minutes/seconds, transform
them to their respective decimal representation.
3. Ensure that coordinates are represented in the correct reference
system / units as described in Section 4.4.1. Transform
coordinates if neccessary.
4. Round coordinate values to a sensible number of decimal places,
according to the presumed accuracy of the data source used.
5. Remove abundant leading zero's from values, keeping at least one
digit in the integer part. Make sure that negative values have a
minus sign, while positive values don't have a sign.
6. concatenate prepared latitude, longitude, optionally altitude
strings with the subcomponent delimiter ",", not adding any
whitespace or other characters.
7. prepend the result with the string 'geo:' (the URI scheme and
delimiter)
8. if the final URI is to include a 'query' component, add the
component delimiter "?" to the end of the result, followed by the
encoded query string.
The following example constructs a 'geo' URI from the location
message of a Global Positioning System (GPS) receiver:
1. Aquire coordinates (data split in two lines):
$GPGGA,124951.000,4812.0556,N,01622.1729,E,1,
05,3.3,192.4,M,43.4,M,,0000*5D
latitude = 48 degrees, 12.0556 minutes north.
longitude = 16 degrees, 22.1729 minutes east.
altitude = 192.4 meters (using a geoid height of 43.4 meters)
Horizontal Dilution of Precision (HDOP) = 3.3 (corresponds to
about 10 meters)
2. Transform into decimal values:
latitude = +48.2009266666 degrees
longitude = +16.3695483333 degrees
altitude = 192.4 meters
3. Reference system: longitude and latitude values are already given
in WGS84, altitude already refers to mean sea level (according to
the geoid correction value of 43.4 meters)
4. Round values:
latitude = +48.20093 degrees
longitude = +016.36955 degrees
altitude = 192 meters
Mayrhofer & Spanring Expires July 6, 2007 [Page 7]
Internet-Draft 'geo' URI scheme January 2007
(five decimal rougly correlate to about one meter on the equator.
This is more precise than the indicated HDOP of about 10 meters).
5. Remove abundant stuff:
latitude = 48.200927
longitude = 16.369548
altitude = 192
6. Concatenate:
48.200927,16.369548,192
7. Prepend with URI scheme name and delimiter:
geo:48.200927,16.369548,192
8. In this example, no query component is to be added.
5.2. URI Dereference
A consumer of a 'geo' URI has to perform the following operation for
dereference:
1. Validate the 'geo' URI against the syntax specification
(Section 4.3). URIs which do not match the syntax SHOULD NOT be
used (see note below).
2. Remove the URI scheme and the URI delimiter ("geo:") from the
beginning of the string.
3. If the string contains a query delimiter ("?"), split off the
'query' component and the query delimiter
4. Split the remaining string into subcomponents, using the comma
(",") as the delimiter
5. Use the first subcomponent as latitude, the second one as
longitude. If a thrid subcomponent is present, use it as
altitude.
Note: An application MAY use URIs which contain whitespace in the
'geo-location' component by stripping it off before the dereference
process.
5.3. URI Operations
Currently, just one operation on a 'geo' URI is defined - location
retrieval: In that operation, a client uses the data from the URI to
retrieve the geographical location to which the URI refers to.
A client may then, though, use this location information for various
Mayrhofer & Spanring Expires July 6, 2007 [Page 8]
Internet-Draft 'geo' URI scheme January 2007
purposes:
A web browser may rewrite 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 may offer the user to start navigation to the location.
Examples of such uses can be found in Section 6.
6. Examples and Use Cases
6.1. Plain 'geo' URI
The following 3-dimensional 'geo' URI example references to the
bottom of the stairs leading to the Karlskirche in Vienna, Austria:
<geo:48.19858,16.37164,171>
A user could type the data extracted from this URI into a electronic
navigation device, or even use it to locate the identified location
on a paper map.
6.2. Hyperlink
'geo' URIs could (like any other URI scheme) also be embedded as
hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet
with such a hyperlink could look like:
<p>one of Vienna's most popular sights is the <a href='geo:
48.19858,16.37164'>Karlskirche</a>
6.3. Header Field
Many protocols support the use of arbitrary URI schemes, for example
in their header Fields. A Session Initiation Protocol (SIP) [7]
REGISTER request could contain a 'Contact' header with a 'geo' URI,
to reflect the geographic location to be used to contact the
registering entity physically:
REGISTER sip:geoaware.example.com SIP/2.0
Via: SIP/2.0/UDP mypc.example.org:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Joe Geo <sip:joe@example.com>
From: Joe Geo <sip:joe@example.com>;tag=456248
Call-ID: aaafafff-84230@7afagggdd
CSeq: 42 REGISTER
Contact: <sip:joe@192.168.1.1>
Mayrhofer & Spanring Expires July 6, 2007 [Page 9]
Internet-Draft 'geo' URI scheme January 2007
Contact: <geo:48.19858,16.37164>
6.4. Web Mapping Services
A rather common method for accessing geographic information on the
Internet are web mapping services (WMS) [6]. An image containing a
map is delivered by a mapserver as response to a WMS request. WMS
requests usually contain a bounding box (enclosing rectangle), the
spatial reference system (e.g. 'EPSG:4326' for WGS84), displayed
layers (e.g. roads, borders), image dimensions and image format (e.g.
'image/png'):
http://map.example.org/maps/wms.cgi?BBOX=16,48,18,50&SRS=EPSG:4326 \
&LAYERS=roads,borders&WIDTH=400&HEIGHT=400&FORMAT=image/png
A location identified by a 'geo' URI could be used to support input
parameters in terms of a center point of a WMS request. Query
parameters could be used to reflect the requested type of service,
eg. a 'geo' URI could be mapped to a WMS request as follows:
geo:48.20833,16.37278,171?service=wms&scale=5000&layers=roads,borders
\ &height=400&width=400&format=image/png
A bounding box can be calculated by given scale, height and width.
In our case, based on an output scale of 1:5000 and 400px image
height and width the bounding box width and height is 0.00634
degrees. A 'geo' URI is limited to one spatial reference system,
thus 'SRS=EPSG:4326' is a constant parameter in WMS transformations.
The resulting WMS request could look like:
http://map.example.org/maps/wms.cgi?BBOX=16.05690,47.89167, \
16.69142,48.52619&SRS= EPSG:4326&LAYERS=roads,borders&WIDTH=400 \
&HEIGHT=400&FORMAT=image/png
7. 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) [4]. The definitions required for the assignment are
contained in Section 4.
8. 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
Mayrhofer & Spanring Expires July 6, 2007 [Page 10]
Internet-Draft 'geo' URI scheme January 2007
3986) do not apply. However, the following (additional) issues
apply:
8.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 <geo:94,0> (latitude
"beyond" north pole).
8.2. Location Privacy
Location information about individuals is an extremely sensitive
topic, especially when location is combined with Personally
Identifyable Information (PII).
In cases where location information about individuals is used in a
publicly available 'geo' URI, the explicit consent of the individual
is REQUIRED.
8.3. Malicious Locations
As with other URI schemes, the information provisioned in 'geo' URIs
cannot be trusted unless some kind of trust relation with the author
of a URI is in place. Applications of the 'geo' URI SHOULD consider
methods of validating and protecting URIs.
9. References
9.1. Normative References
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Mayrhofer & Spanring Expires July 6, 2007 [Page 11]
Internet-Draft 'geo' URI scheme January 2007
9.2. Informative References
[4] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, RFC 4395,
February 2006.
[5] National Imagery and Mapping Agency, "Department of Defense
World Geodetic System 1984, Third Edition", NIMA TR8350.2,
January 2000.
[6] Open GIS Consortium Inc., "Web Map Service Implementations
Specification, Version 1.1.1", OGC 01-068r3, January 2002.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Authors' Addresses
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Christian Spanring
OIR-Informationsdienste GmbH
Franz-Josefs-Kai 27
Wien A-1010
Phone: +43 1 5338747 36
Email: spanring@oir.at
URI: http://www.oir.at/
Mayrhofer & Spanring Expires July 6, 2007 [Page 12]
Internet-Draft 'geo' URI scheme January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Mayrhofer & Spanring Expires July 6, 2007 [Page 13]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/