GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group nic.at
Internet-Draft C. Spanring
Expires: August 16, 2009 OIR-ID
February 12, 2009
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-mayrhofer-geopriv-geo-uri-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 16, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract
This document specifies an Uniform Resource Identifier (URI) for
Mayrhofer & Spanring Expires August 16, 2009 [Page 1]
Internet-Draft 'geo' URI scheme February 2009
geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location by latitude, longitude and optionally
altitude in a compact, simple, human-readable, and protocol
independent way.
Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6
4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6
4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6
4.4.1. Component Description . . . . . . . . . . . . . . . . 6
4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 7
4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 7
4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 7
4.6. Applications/protocols That Use This URI Scheme . . . . . 8
4.7. Interopability Considerations . . . . . . . . . . . . . . 8
4.8. Security Considerations . . . . . . . . . . . . . . . . . 8
4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.10. Author/Change controller . . . . . . . . . . . . . . . . . 8
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 9
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 9
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 9
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 10
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 10
7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 11
7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 11
7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 12
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 13
Mayrhofer & Spanring Expires August 16, 2009 [Page 2]
Internet-Draft 'geo' URI scheme February 2009
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Mayrhofer & Spanring Expires August 16, 2009 [Page 3]
Internet-Draft 'geo' URI scheme February 2009
1. Change Log
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-mayrhofer-geopriv-geo-uri-01
o added terminology text about WGS-84 (credits Carl Reed)
o removed "resolution" / "uncertainty" text
o added considerations regarding poles
o added text about invalid URIs
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
extended by specifications for adding spatial (geographic) location.
In most cases, latitude as well as longitude of simple points are
added as new attributes to existing data structures. However, all
those methods are very specific to a certain data format or protocol,
and don't provide a protocol independent, compact and generic way to
refer to a physical geographic location.
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
Mayrhofer & Spanring Expires August 16, 2009 [Page 4]
Internet-Draft 'geo' URI scheme February 2009
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
identifies geographic locations (a physical resource) in the World
Geodetic System 1984 (WGS-84) [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, and can be used in any other protocol or data format
that supports inclusion of arbitrary URIs.
The definition of the URI scheme is strictly focused on the most
simplest representation of a spatial location - a single point. The
provision of more complex geometries or locations described by civic
addresses is out of scope of this document.
Note: The choice of WGS-84 is based on the widespread availability of
Global Positioning System (GPS) devices, which use the WGS-84
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.
Also, many other data formats for representing geographic locations
use the WGS-84 reference system, which makes transposing from and to
such data formats less error prone (no re-projection involved).
3. Terminology
Geographic locations in this document are defined using WGS 84 (World
Geodetic System 1984), equivalent to the OGP Surveying and
Positioning Committee EPSG code 4326 (2 dimensions) and 4979 (3
dimensions). This document does not assign responsibilities for
coordinate transformations from and to other Spatial Reference
Systems.
A 2-dimensional WGS-84 coordinate value is here represented as a
comma-delimited latitude/longitude pair, measured in decimal degrees
(un-projected). A 3-dimensional WGS-84 coordinate value is here
represented by appending a comma-delimited altitude value in meters
to such pairs.
Latitudes range from -90 to 90 and longitudes range from -180 to 180.
Coordinates in the Southern and Western hemispheres as well as
Mayrhofer & Spanring Expires August 16, 2009 [Page 5]
Internet-Draft 'geo' URI scheme February 2009
altitudes below the WGS-84 reference geoid are signed negative with a
leading dash.
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]:
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
Data contained in a 'geo' URI identifies a physical resource: A
spatial location on earth in the WGS-84 references system, identified
by the geographic coordinates encoded 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:
Mayrhofer & Spanring Expires August 16, 2009 [Page 6]
Internet-Draft 'geo' URI scheme February 2009
o The "latitude" component MUST contain the latitude of the
identified location in decimal degrees in the reference system
WGS-84.
o The "latitude" component MUST contain the latitude of the
identified location in decimal degrees in the reference system
WGS-84.
o If present, the OPTIONAL "altitude" component MUST contain the
WGS-84 altitude of the identified location in meters.
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 "longitude" components of coordinate values reflecting the poles
(latitude set to -90 or 90 degrees) SHOULD be set to "0", although
consumers of "geo" URIs MUST accept such URIs with any longitude
value between -180 and 180.
'geo' URIs with longitude values outside the range of -180 to 180
decimal degrees or with latitude values outside the range of -90 to
90 degrees MUST be considered invalid.
4.4.2. URI Comparison
Two 'geo' URIs are equal when their 'longitude', 'latitude' and
'altitude' values are mathematically identical. Where the 'latitude'
component of a 'geo' URI is set to either 90 or -90 degrees, the
'longitude' component MUST be ignored in comparison operations.
An URI with undefined (missing) 'altitude' value MUST NOT be
considered equal to an URI containing an 'altitude' value, even if
the remaining values 'latitude' and 'longitude' are equivalent.
4.4.3. Interpretation of Undefined Altitude
A consumer of a 'geo' URI with undefined 'altitude' MAY assume that
the URI refers to the respective location on earth's physical surface
at the given 'latitude' and 'longitude' coordinate.
However, as defined above, altitudes are relative to the WGS-84
reference geoid rather than earth's surface. Hence, an altitude
value of 0 MUST NOT be interpreted as "on earth's surface".
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
Mayrhofer & Spanring Expires August 16, 2009 [Page 7]
Internet-Draft 'geo' URI scheme February 2009
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
As many other URI scheme definitions, 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
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. However, the simple structure of the 'geo' URI would even
allow manual dereference by users.
Poorly authored 'geo' URI instances could contain whitespace and
numbers with leading plus signs ("+"). Clients SHOULD try to
dereference such URIs after removing such whitespace and plus signs.
This specification does not define any URI parameters nor a query
component. Future revisions might define such parameters, using the
";" and "?" characters to delimit parameter and query components from
the path component specified above. Clients MUST be prepared to
encounter such 'geo' URI instances, and MUST 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@nic.at,
http://timatio.com/ )
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.
Mayrhofer & Spanring Expires August 16, 2009 [Page 8]
Internet-Draft 'geo' URI scheme February 2009
4.11. References
RFC XXXX [change to RFC number once assigned]
5. 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:
o A web browser could use that information to open a web mapping
service of the user's choice, and display a map of the location
o A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location.
6. Use Cases and Examples
6.1. Plain 'geo' URI Example
The following 3-dimensional 'geo' URI example references to the
office location of one of the authors in Vienna, Austria:
geo:48.2010,16.3695,183
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 (like any other URI scheme) could 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 popular sights is the <a href='geo:
48.198634,16.371648'>Karlskirche</a>.
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 August 16, 2009 [Page 9]
Internet-Draft 'geo' URI scheme February 2009
o display a small map thumbnail 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 comparing the 'geo' URI
with locations extracted from GeoRSS feeds the user has subscribed
to.
o Convert the coordinates to a format suitable for uploading to a
navigation device
6.3. 'geo' URI in 2-dimensional barcode
Due to it's short length, a 'geo' URI could easily be encoded in
2-dimensional barcodes. Such barcodes could be printed on business
cards, flyers, paper maps and subsequently used by mobile devices,
for example as follows:
1. User identifies such a barcode on a flyer, uses the camera on his
mobile phone to photograph and decode the barcode
2. The mobile phone dereferences the 'geo' URI, and offers the user
to calculate a navigation route to the identified location.
3. Using the builtin GPS, the user follows the navgiation
instructions from his phone to reach the destination
7. GML Mappings
The Geographic Markup Language (GML) by the Open Geospatial
Consortium (OGC) is a set of XML schemas to represent geographical
features. Since GML is widely accepted, this document includes
instructions on how to transpose 'geo' URIs from and to GML
documents.
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, "%lat%",
"%lon%" and "%alt%" are placeholders for latitude, longitude, and
altitude values. Mappings are defined as follows:
7.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:
Mayrhofer & Spanring Expires August 16, 2009 [Page 10]
Internet-Draft 'geo' URI scheme February 2009
'geo' URI:
geo:%lat%,%lon%
GML document:
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="2"
srsName="urn:ogc:def:crs:EPSG:6.6:4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
7.2. 'geo' URI with Altitude to GML 'Point'
A 'geo' URI instance with the altitude element is mapped to a three-
dimensional GML "Point" as follows:
'geo' URI:
geo:%lat%,%lon%,%alt%
GML document:
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
7.3. GML 'Point' without Altitude to 'geo' URI
A GML 'Point' in the reference system identified as
"urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows:
GML document:
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="2"
srsName="urn:ogc:def:crs:EPSG:6.6:4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
'geo' URI:
geo:%lat%,%lon%
Mayrhofer & Spanring Expires August 16, 2009 [Page 11]
Internet-Draft 'geo' URI scheme February 2009
Note: GML documents in other reference systems MAY be used as well if
a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and
applied before the mapping step.
7.4. GML 'Point' with Altitude to 'geo' URI
A GML 'Point' in the reference system identified as
"urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows:
GML document:
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
'geo' URI:
geo:%lat%,%lon%
Note: GML 'Point' instances in other reference systems MAY be used as
well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is
defined and applied before the mapping step.
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
Mayrhofer & Spanring Expires August 16, 2009 [Page 12]
Internet-Draft 'geo' URI scheme February 2009
warn the user when such URIs are encountered.
An example of such an invalid URI would be <geo:94,0> (latitude
"beyond" north pole).
9.2. Location Privacy
Location information about individuals is an extremely sensitive
topic, especially when location is combined with Personally
Identifyable Information (PII). Authors of 'geo' URIs MUST consider
data protection and privacy before publishing such URIs.
10. Acknowledgements
The authors wish to acknowledge the helpful contributions from Carl
Reed, Bill McQuillan, Martin Kofal, Andrew Turner and Kim Sanders.
11. References
11.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC3261] 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.
11.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Third Edition",
NIMA TR8350.2, January 2000.
Mayrhofer & Spanring Expires August 16, 2009 [Page 13]
Internet-Draft 'geo' URI scheme February 2009
Authors' Addresses
Alexander Mayrhofer
nic.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@nic.at
URI: http://www.nic.at/
Christian Spanring
OIR-ID 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 August 16, 2009 [Page 14]