GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5870

Internet Engineering Task Force (IETF) A. Mayrhofer Request for Comments: 5870 IPCom Category: Standards Track C. Spanring ISSN: 2070-1721 June 2010

 A Uniform Resource Identifier for Geographic Locations ('geo' URI)

Abstract

 This document specifies a Uniform Resource Identifier (URI) for
 geographic locations using the 'geo' scheme name.  A 'geo' URI
 identifies a physical location in a two- or three-dimensional
 coordinate reference system in a compact, simple, human-readable, and
 protocol-independent way.  The default coordinate reference system
 used is the World Geodetic System 1984 (WGS-84).

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5870.

Mayrhofer & Spanring Standards Track [Page 1] RFC 5870 'geo' URI Scheme June 2010

Copyright Notice

 Copyright (c) 2010 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.
 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.

Mayrhofer & Spanring Standards Track [Page 2] RFC 5870 'geo' URI Scheme June 2010

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  IANA Registration of the 'geo' URI Scheme  . . . . . . . . . .  6
   3.1.  URI Scheme Name  . . . . . . . . . . . . . . . . . . . . .  6
   3.2.  Status . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.3.  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . .  6
   3.4.  URI Scheme Semantics . . . . . . . . . . . . . . . . . . .  7
     3.4.1.  Coordinate Reference System Identification . . . . . .  7
     3.4.2.  Component Description for WGS-84 . . . . . . . . . . .  8
     3.4.3.  Location Uncertainty . . . . . . . . . . . . . . . . .  8
     3.4.4.  URI Comparison . . . . . . . . . . . . . . . . . . . .  9
     3.4.5.  Interpretation of Undefined Altitude . . . . . . . . . 10
   3.5.  Encoding Considerations  . . . . . . . . . . . . . . . . . 10
   3.6.  Applications/Protocols That Use This URI Scheme  . . . . . 11
   3.7.  Interoperability Considerations  . . . . . . . . . . . . . 11
   3.8.  Security Considerations  . . . . . . . . . . . . . . . . . 11
   3.9.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.10. Author/Change Controller . . . . . . . . . . . . . . . . . 12
   3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12
 4.  'geo' URI Parameters Registry  . . . . . . . . . . . . . . . . 12
 5.  URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 13
 6.  Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13
   6.1.  Plain 'geo' URI Example  . . . . . . . . . . . . . . . . . 13
   6.2.  Hyperlink  . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.3.  'geo' URI in 2-Dimensional Barcode . . . . . . . . . . . . 15
   6.4.  Comparison Examples  . . . . . . . . . . . . . . . . . . . 15
 7.  GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.1.  2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 17
   7.2.  3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 17
   7.3.  GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 17
   7.4.  GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 18
 8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.1.  'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 18
   8.2.  URI Parameter Registry . . . . . . . . . . . . . . . . . . 19
     8.2.1.  Registry Contents  . . . . . . . . . . . . . . . . . . 19
     8.2.2.  Registration Policy  . . . . . . . . . . . . . . . . . 19
   8.3.  Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 20
     8.3.1.  Registry Contents  . . . . . . . . . . . . . . . . . . 20
     8.3.2.  Registration Policy  . . . . . . . . . . . . . . . . . 20
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.1.  Invalid Locations  . . . . . . . . . . . . . . . . . . . . 21
   9.2.  Location Privacy . . . . . . . . . . . . . . . . . . . . . 21
 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
   11.2. Informative References . . . . . . . . . . . . . . . . . . 22

Mayrhofer & Spanring Standards Track [Page 3] RFC 5870 'geo' URI Scheme June 2010

1. 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.
 Location-aware applications and location-based services are fast
 emerging on the Internet.  Most web search engines use geographic
 information, and a vivid open source mapping community has brought an
 enormous momentum into location aware technology.  A wide range of
 tools and data sets that formerly were accessible to professionals
 only recently have become available to a wider audience.
 The 'geo' URI scheme is another step in that direction and aims to
 facilitate, support, and standardize the problem of location
 identification in geospatial services and applications.  Accessing
 information about a particular location or triggering further
 services shouldn't be any harder than clicking on a 'mailto:' link
 and writing 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 (physical resources) in a coordinate
 reference system (CRS), which is, by default, the World Geodetic
 System 1984 (WGS-84) [WGS84].  The scheme provides the textual
 representation of the location's spatial coordinates in either two or
 three dimensions (latitude, longitude, and optionally altitude for
 the default CRS of WGS-84).  An example of such a 'geo' URI follows:
    geo:13.4125,103.8667
 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.
 For the sake of usability, the definition of the URI scheme is
 strictly focused on the simplest, but also most common representation
 of a spatial location -- a single point in a well known CRS.  The
 provision of more complex geometries or locations described by civic
 addresses is out of scope of this document.

Mayrhofer & Spanring Standards Track [Page 4] RFC 5870 'geo' URI Scheme June 2010

 The optional 'crs' URI parameter described below may be used by
 future specifications to define the use of CRSes other than WGS-84.
 This is primarily intended to cope with the case of another CRS
 replacing WGS-84 as the predominantly used one, rather than allowing
 the arbitrary use of thousands of CRSes for the URI (which would
 clearly affect interoperability).  The definition of 'crs' values
 beyond the default of "wgs84" is therefore out of scope of this
 document.
 This specification discourages use of alternate CRSes in use cases
 where comparison is an important function.
 Note: The choice of WGS-84 as the default CRS 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 will 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).  It is also believed that the burden of
 potentially required spatial transformations should be put on the
 author rather then the consumer of 'geo' URI instances.
 Because of their similar structure, 'geo' URI instances can also be
 mapped from and to certain ISO 6709 [ISO.6709.2008] string
 representations of geographic point locations.

2. Terminology

 Geographic locations in this document are defined using WGS-84 (World
 Geodetic System 1984), which is equivalent to the International
 Association of Oil & Gas Producers (OGP) Surveying and Positioning
 Committee EPSG (European Petroleum Survey Group) codes 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 represented here as a
 comma-delimited latitude/longitude pair, measured in decimal degrees
 (un-projected).  A 3-dimensional WGS-84 coordinate value is
 represented here 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
 altitudes below the WGS-84 reference geoid (depths) are signed
 negative with a leading dash.

Mayrhofer & Spanring Standards Track [Page 5] RFC 5870 'geo' URI Scheme June 2010

 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].

3. IANA Registration of the 'geo' URI Scheme

 This section contains the fields required for the URI scheme
 registration, following the guidelines in Section 5.4 of [RFC4395].

3.1. URI Scheme Name

 geo

3.2. Status

 permanent

3.3. URI Scheme Syntax

 The syntax of the 'geo' URI scheme is specified below in Augmented
 Backus-Naur Form (ABNF) [RFC5234]:
           geo-URI       = geo-scheme ":" geo-path
           geo-scheme    = "geo"
           geo-path      = coordinates p
           coordinates   = coord-a "," coord-b [ "," coord-c ]
           coord-a       = num
           coord-b       = num
           coord-c       = num
           p             = [ crsp ] [ uncp ] *parameter
           crsp          = ";crs=" crslabel
           crslabel      = "wgs84" / labeltext
           uncp          = ";u=" uval
           uval          = pnum
           parameter     = ";" pname [ "=" pvalue ]
           pname         = labeltext
           pvalue        = 1*paramchar
           paramchar     = p-unreserved / unreserved / pct-encoded
           labeltext     = 1*( alphanum / "-" )
           pnum          = 1*DIGIT [ "." 1*DIGIT ]
           num           = [ "-" ] pnum
           unreserved    = alphanum / mark
           mark          = "-" / "_" / "." / "!" / "~" / "*" /
                           "'" / "(" / ")"
           pct-encoded   = "%" HEXDIG HEXDIG

Mayrhofer & Spanring Standards Track [Page 6] RFC 5870 'geo' URI Scheme June 2010

           p-unreserved  = "[" / "]" / ":" / "&" / "+" / "$"
           alphanum      = ALPHA / DIGIT
 Parameter names are case insensitive, but use of the lowercase
 representation is preferred.  Case sensitivity of non-numeric
 parameter values MUST be described in the specification of the
 respective parameter.  For the 'crs' parameter, values are case
 insensitive, and lowercase is preferred.
 Both 'crs' and 'u' parameters MUST NOT appear more than once each.
 The 'crs' and 'u' parameters MUST be given before any other
 parameters that may be defined in future extensions.  The 'crs'
 parameter MUST be given first if both 'crs' and 'u' are used.  The
 definition of other parameters, and <crslabel> values beyond the
 default value of "wgs84" is out of the scope of this document.
 Section 8.2 discusses the IANA registration of such additional
 parameters and values.
 The value of "-0" for <num> is allowed and is identical to "0".
 In case the URI identifies a location in the default CRS of WGS-84,
 the <coordinates> sub-components are further restricted as follows:
           coord-a        = latitude
           coord-b        = longitude
           coord-c        = altitude
           latitude       = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
           longitude      = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
           altitude       = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]

3.4. URI Scheme Semantics

 Data contained in a 'geo' URI identifies a physical resource: a
 spatial location identified by the geographic coordinates and the CRS
 encoded in the URI.

3.4.1. Coordinate Reference System Identification

 The semantics of <coordinates> depends on the CRS of the URI.  The
 CRS itself is identified by the optional 'crs' parameter.  A URI
 instance uses the default WGS-84 CRS if the 'crs' parameter is either
 missing or contains the value of 'wgs84'.  Other <crslabel> values
 are currently not defined, but may be specified by future documents.
 Interpretation of coordinates in the wrong CRS produces invalid
 location information.  Consumers of 'geo' URIs therefore MUST NOT
 ignore the 'crs' parameter if given, and MUST NOT interpret the

Mayrhofer & Spanring Standards Track [Page 7] RFC 5870 'geo' URI Scheme June 2010

 <coordinates> sub-components without considering and understanding
 the 'crs' parameter value.
 The following component description refers to the use of the default
 CRS (WGS-84) only.  Future documents specifying other 'crs' parameter
 values MUST provide similar descriptions for the <coordinates> sub-
 components in the described CRS.

3.4.2. Component Description for WGS-84

 The <latitude>, <longitude>, and <altitude> components as specified
 in the URI scheme syntax (Section 3.3) are to be used as follows:
 o  <latitude> MUST contain the latitude of the identified location in
    decimal degrees in the reference system WGS-84.
 o  <longitude> MUST contain the longitude of the identified location
    in decimal degrees in the reference system WGS-84.
 o  If present, the OPTIONAL <altitude> MUST contain the altitude of
    the identified location in meters in the reference system WGS-84.
 If the altitude of the location is unknown, <altitude> (and the comma
 before) MUST NOT be present in the URI.  Specifically, unknown
 altitude MUST NOT be represented by setting <altitude> to "0" (or any
 other arbitrary value).
 The <longitude> 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 from -180
 to 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.

3.4.3. Location Uncertainty

 The 'u' ("uncertainty") parameter indicates the amount of uncertainty
 in the location as a value in meters.  Where a 'geo' URI is used to
 identify the location of a particular object, <uval> indicates the
 uncertainty with which the identified location of the subject is
 known.
 The 'u' parameter is optional and it can appear only once.  If it is
 not specified, this indicates that uncertainty is unknown or
 unspecified.  If the intent is to indicate a specific point in space,

Mayrhofer & Spanring Standards Track [Page 8] RFC 5870 'geo' URI Scheme June 2010

 <uval> MAY be set to zero.  Zero uncertainty and absent uncertainty
 are never the same thing.
 The single uncertainty value is applied to all dimensions given in
 the URI.
 Note: The number of digits of the values in <coordinates> MUST NOT be
 interpreted as an indication to the level of uncertainty.

3.4.4. URI Comparison

 Comparison of URIs intends to determine whether two URI strings are
 equivalent and identify the same resource (rather than comparing the
 resources themselves).  Therefore, a comparison of two 'geo' URIs
 does not compare spatial objects, but only the strings (URIs)
 identifying those objects.
 The term "mathematically identical" used below specifies that some
 components of the URI MUST be compared as normalized numbers rather
 than strings to account for the variety in string representations of
 identical numbers (for example, the strings "43.10" and "43.1" are
 different, but represent the same number).
 Two 'geo' URIs are equal only if they fulfill all of the following
 general comparison rules:
 o  Both URIs use the same CRS, which means that either both have the
    'crs' parameter omitted, or both have the same <crslabel> value,
    or one has the 'crs' parameter omitted while the other URI
    specifies the default CRS explicitly with a <crslabel> value of
    "wgs84".
 o  Their <coord-a>, <coord-b>, <coord-c> and 'u' values are
    mathematically identical (including absent <uval> meaning
    undefined 'u' value).
 o  Their sets of other parameters are equal, with comparison
    operations applied on each parameter as described in its
    respective specification.
 Parameter order is not significant for URI comparison.
 Since new parameters may be registered over time, legacy
 implementations of the 'geo' URI might encounter unknown parameters.
 In such cases, the following rules apply:

Mayrhofer & Spanring Standards Track [Page 9] RFC 5870 'geo' URI Scheme June 2010

 o  Two 'geo' URIs with unknown parameters are equivalent only if the
    same set of unknown parameter names appears in each URI, and their
    values are bitwise identical after percent-decoding.
 o  Otherwise, the comparison operation for the respective URIs is
    undefined (since the legacy implementation cannot be aware of the
    comparison rules for those parameters).
 Designers of future extension parameters should take this into
 account when choosing the comparison rules for new parameters.
 A URI with an undefined (missing) <coord-c> (altitude) value MUST NOT
 be considered equal to a URI containing a <coord-c>, even if the
 remaining <coord-a>, <coord-b>, and 'u' values are equivalent.
 For the default CRS of WGS-84, the following comparison rules apply
 additionally:
 o  Where <latitude> of a 'geo' URI is set to either 90 or -90
    degrees, <longitude> MUST be ignored in comparison operations
    ("poles case").
 o  A <longitude> of 180 degrees MUST be considered equal to
    <longitude> of -180 degrees for the purpose of URI comparison
    ("date line" case).

3.4.5. Interpretation of Undefined Altitude

 A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude>
 MAY assume that the URI refers to the respective location on Earth's
 physical surface at the given latitude and longitude.
 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 mistaken to refer to "ground elevation".

3.5. Encoding Considerations

 The <coordinates> path component of the 'geo' URI (see Section 3.3)
 uses a comma (",") as the delimiter for subcomponents.  This
 delimiter MUST NOT be percent-encoded.
 It is RECOMMENDED that for readability the contents of <coord-a>,
 <coord-b>, and <coord-c> as well as <crslabel> and <uval> are never
 percent-encoded.
 Regarding internationalization, the currently specified components do
 allow for ASCII characters exclusively, and therefore don't require

Mayrhofer & Spanring Standards Track [Page 10] RFC 5870 'geo' URI Scheme June 2010

 internationalization.  Future specifications of additional parameters
 might allow the introduction of non-ASCII values.  Such
 specifications MUST describe internationalization considerations for
 those parameters and their values, and MUST require percent-encoding
 of non-ASCII values.

3.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.

3.7. Interoperability Considerations

 Like other new URI schemes, the 'geo' URI requires support in client
 applications.  Users of applications that are not aware of the 'geo'
 scheme are likely not able to make direct use of the information in
 the URI.  However, a client can make indirect use by passing around
 'geo' URIs, even without understanding the format and semantics of
 the scheme.  Additionally, the simple structure of 'geo' URIs would
 allow even manual dereference by humans.
 Clients MUST NOT attempt to dereference 'geo' URIs given in a CRS
 that is unknown to the client, because doing so would produce
 entirely bogus results.
 Authors of 'geo' URIs should carefully check that coordinate
 components are set in the right CRS and in the specified order, since
 the wrong order of those components (or use of coordinates in a
 different CRS without transformation) are commonly observed mistakes
 producing completely bogus locations.
 The number of digits in the <coordinates> values MUST NOT be
 interpreted as an indication of a certain level of accuracy or
 uncertainty.

3.8. Security Considerations

 See Section 9 of RFC 5870.

3.9. Contact

    Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
    Christian Spanring <christian@spanring.eu>

Mayrhofer & Spanring Standards Track [Page 11] RFC 5870 'geo' URI Scheme June 2010

3.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.

3.11. References

 RFC 5870

4. 'geo' URI Parameters Registry

 This specification creates a new IANA Registry named "'geo' URI
 Parameters" registry for the <parameter> component of the URI.
 Parameters for the 'geo' URI and values for these parameters MUST be
 registered with IANA to prevent namespace collisions and provide
 interoperability.
 Some parameters accept values that are constrained by a syntax
 definition only, while others accept values from a predefined set
 only.  Some parameters might not accept any values at all ("flag"
 type parameters).
 The registration of values is REQUIRED for parameters that accept
 values from a predefined set.
 The specification of a parameter MUST fully explain the syntax,
 intended usage, and semantics of the parameter.  This ensures
 interoperability between independent implementations.
 For parameters that are neither restricted to a set of predefined
 values nor the "flag" type described above, the syntax of allowed
 values MUST be described in the specification, for example by using
 ABNF.
 Documents defining new parameters (or new values for existing
 parameters) MUST register them with IANA, as explained in
 Section 8.2.
 The 'geo' URI Parameter Registry contains a column named "Value
 Restriction" that describes whether or not a parameter accepts a
 value, and whether values are restricted to a predefined set.  That
 column accepts the following values:
 o  "No value": The parameter does not accept any values and is to be
    used as a "flag" only.

Mayrhofer & Spanring Standards Track [Page 12] RFC 5870 'geo' URI Scheme June 2010

 o  "Predefined": The parameter does accept values from a predefined
    set only, as specified in an RFC or other permanent and readily
    available public specification.
 o  "Constrained": The parameter accepts arbitrary values that are
    only constrained by a syntax as specified in an RFC or other
    permanent and readily available public specification.
 Section 8.2.1 contains the initial contents of the Registry.

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
 <geo-path>.  Further use of those coordinates (and the uncertainty
 value from <uval>) is then up to the application processing the URI,
 and might depend on the context of 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 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 the ability to start navigation to
    the location.
 Note that the examples and use cases above as well as in the next
 section are non-normative, and are provided for information only.

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
 Resolution of the URI returns the following information:
 o  The 'crs' parameter is not given in the URI, which means that the
    URI uses the default CRS of WGS-84.
 o  The URI includes <coord-c>, is hence 3-dimensional, and therefore
    uses 'urn:ogc:def:crs:EPSG::4979' as the WGS-84 CRS identifier.

Mayrhofer & Spanring Standards Track [Page 13] RFC 5870 'geo' URI Scheme June 2010

 o  The <coord-a> value (latitude in WGS-84) is set to '48.2010'
    decimal degrees.
 o  The <coord-b> value (longitude in WGS-84) is set to '16.3695'
    decimal degrees.
 o  The <coord-c> value (altitude in WGS-84) is set to 183 meters.
 o  Uncertainty is undefined.
 A user could type the data extracted from this URI into an 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;crs=wgs84;u=40'>Karlskirche</a>.
 Resolution of the URI returns the following information:
 o  The 'crs' is given in the URI and sets the CRS used in the URI to
    WGS-84 explicitly.
 o  The URI does omit <coord-c>, is hence 2-dimensional, and therefore
    uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier.
 o  The <coord-a> value (latitude in WGS-84) is set to '48.198634'
    decimal degrees.
 o  The <coord-b> value (longitude in WGS-84) is set to '16.371648'
    decimal degrees.
 o  The <coord-c> (altitude) value is undefined; therefore, the client
    MAY assume the identified location to be on Earth's physical
    surface.
 o  The 'u' parameter is included in the URI, setting uncertainty to
    40 meters.
 A web browser could use this information from the HTML snippet, and
 offer the user various options (based on configuration, context), for
 example:

Mayrhofer & Spanring Standards Track [Page 14] RFC 5870 'geo' URI Scheme June 2010

 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 to which the user has
    subscribed.
 o  Convert the coordinates to a format suitable for uploading to a
    navigation device.
 Note that the URI in this example also makes use of the explicit
 specification of the CRS by using the 'crs' parameter.

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, and paper maps, and subsequently used by mobile
 devices, for example as follows:
 1.  User identifies such a barcode on a flyer and 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
     the ability to calculate a navigation route to the identified
     location.
 3.  Using the builtin GPS receiver, the user follows the navigation
     instructions to reach the location.

6.4. Comparison Examples

 This section provides examples of URI comparison.  Note that the
 unknown parameters 'foo' and 'bar' and unregistered 'crs' values in
 this section are used for illustrative purposes only, and their
 inclusion in the examples below does not constitute any formal
 parameter definition or registration request.
 o  The two URIs <geo:90,-22.43;crs=WGS84> and <geo:90,46> are equal,
    because both use the same CRS, and even though the longitude
    values are different, both reflect a location on the north pole
    (special "poles" rule for WGS-84 applies - longitude is to be
    ignored).  Note that the 'crs' parameter values are case
    insensitive.

Mayrhofer & Spanring Standards Track [Page 15] RFC 5870 'geo' URI Scheme June 2010

 o  The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal,
    because their coordinate components are mathematically identical.
 o  The set of <geo:66,30;u=6.500;FOo=this%2dthat> and <geo:
    66.0,30;u=6.5;foo=this-that> are identical, because the value of
    the unknown parameter 'foo' is bitwise identical after percent-
    decoding; parameter names are case insensitive, and coordinates
    and uncertainty are mathematically identical.
 o  The comparison operation on <geo:70,20;foo=1.00;bar=white> and
    <geo:70,20;foo=1;bar=white> in a legacy implementation is
    undefined, because the normalization rules for 'foo' are not
    known, and hence the implementation cannot identify whether or not
    '1.00' is identical to '1' for the 'foo' parameter.
 o  Comparing <geo:47,11;foo=blue;bar=white> and <geo:
    47,11;bar=white;foo=blue> returns true, because parameter order is
    insignificant in comparison operations.
 o  The comparison operation on <geo:22,0;bar=Blue> and <geo:
    22,0;BAR=blue> is undefined, because even though parameter names
    are case insensitive, this is not necessarily the case for the
    values of the unknown 'bar' parameter.

7. GML Mappings

 The Geographic Markup Language (GML) by the Open Geospatial
 Consortium (OGC) is a set of XML schemas that represent geographical
 features.  Since GML is widely accepted, this document includes
 instructions on how to transform 'geo' URIs from and to GML
 fragments.  The instructions in this section are not normative.
 For the following sections, "%lat%", "%lon%", "%alt%", and "%unc%"
 are placeholders for latitude, longitude, altitude, and uncertainty
 values, respectively.  The mappings use WGS-84 and are defined in the
 following sections.
 Note: GML fragments in other reference systems could be used as well
 if a transformation into "urn:ogc:def:crs:EPSG::4979" or
 "urn:ogc:def:crs:EPSG::4326" is defined and applied before the
 mapping step.  Such transformations are typically not lossless.
 GML uses the 'double' type from XML schema, and the mapping examples
 assume that numbers in the form of "3.32435e2" in GML are properly
 converted to fixed point when placed into the 'geo' URI.

Mayrhofer & Spanring Standards Track [Page 16] RFC 5870 'geo' URI Scheme June 2010

7.1. 2D GML 'Point'

 A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
 two coordinates and an uncertainty ('u') parameter that is absent or
 zero.  A GML point is always converted to a 'geo' URI that has no
 uncertainty parameter.
 'geo' URI:
    geo:%lat%,%lon%
 GML fragment:
   <Point srsName="urn:ogc:def:crs:EPSG::4326"
          xmlns="http://www.opengis.net/gml">
     <pos>%lat% %lon%</pos>
   </Point>
 Note that a 'geo' URI with an uncertainty value of zero is converted
 to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo'
 URI with zero uncertainty.

7.2. 3D GML 'Point'

 A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
 three coordinates and an uncertainty parameter that is absent or
 zero.  A GML point is always converted to a 'geo' URI that has no
 uncertainty parameter.
 'geo' URI:
    geo:%lat%,%lon%,%alt%
 GML fragment:
   <Point srsName="urn:ogc:def:crs:EPSG::4979"
          xmlns="http://www.opengis.net/gml">
     <pos>%lat% %lon% %alt%</pos>
   </Point>

7.3. GML 'Circle'

 A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two
 coordinates and an uncertainty parameter that is present and non-
 zero.

Mayrhofer & Spanring Standards Track [Page 17] RFC 5870 'geo' URI Scheme June 2010

 'geo' URI:
    geo:%lat%,%lon%;u=%unc%
 GML fragment:
    <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0">
      <gml:pos>%lat% %lon%</gml:pos>
      <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
        %unc%
      </gs:radius>
    </gs:Circle>

7.4. GML 'Sphere'

 A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has
 three coordinates and an uncertainty parameter that is present and
 non-zero.
 'geo' URI:
    geo:%lat%,%lon%,%alt%;u=%unc%
 GML fragment:
    <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0">
      <gml:pos>%lat% %lon% %alt%</gml:pos>
      <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
        %unc%
      </gs:radius>
    </gs:Sphere>

8. IANA Considerations

8.1. 'geo' URI Scheme

 This document creates 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 3.

Mayrhofer & Spanring Standards Track [Page 18] RFC 5870 'geo' URI Scheme June 2010

8.2. URI Parameter Registry

 This document creates a new IANA Registry named "'geo' URI
 Parameters", according to the information in Section 4 and the
 definition in this section.

8.2.1. Registry Contents

 When registering a new 'geo' URI Parameter, the following information
 MUST be provided:
 o  Name of the Parameter.
 o  Whether the Parameter accepts no value ("No value"), values from a
    predefined set ("Predefined"), or values constrained by a syntax
    only ("Constrained").
 o  Reference to the RFC or other permanent and readily available
    public specification defining the parameters and the new values.
 Unless specific instructions exist for a Parameter (like the
 definition of a Sub-registry), the following information MUST be
 provided when registering new values for existing "Predefined" 'geo'
 URI Parameters:
 o  Name of the Parameter.
 o  Reference to the RFC or other permanent and readily available
    public specification defining the new values.
 The following table provides the initial values for this registry:
     Parameter Name          Value Restriction     Reference(s)
     ----------------------------------------------------------
     crs                     Predefined            [RFC5870]
     u                       Constrained           [RFC5870]

8.2.2. Registration Policy

 The Registration Policy for 'geo' URI Parameters and their value
 definitions is "Specification Required" (which implies "Designated
 Expert"), as defined in [RFC5226].

Mayrhofer & Spanring Standards Track [Page 19] RFC 5870 'geo' URI Scheme June 2010

8.3. Sub-Registry for 'crs' Parameter

 This document creates a new IANA Sub-registry named "'geo' URI 'crs'
 Parameter Values", based on the Registry specified in Section 8.2 and
 the information in this section and Section 4.  The syntax of the
 'crs' parameter is constrained by the ABNF given in Section 3.3.

8.3.1. Registry Contents

 When registering a new value for the 'crs' parameter, the following
 information MUST be provided:
 o  Value of the parameter.
 o  Reference to the RFC or other permanent and readily available
    public specification defining the use of the CRS in the scope of
    the 'geo' URI.  The specification should contain information that
    is similar to the WGS-84-specific text given in this document.
 o  Reference to the definition document of the CRS.  If a URN is
    assigned to the CRS, the use of such URN as reference is
    preferred.  Note that different URNs may exist for the
    2-dimensional and 3-dimensional case.
 The following table provides the initial values for this registry:
       crs Value     CRS definition(s)               Reference(s)
       -----------------------------------------------------------
       wgs84         urn:ogc:def:crs:EPSG::4326      [RFC5870]
                     urn:ogc:def:crs:EPSG::4979      [RFC5870]

8.3.2. Registration Policy

 The registration policy for the "'geo' URI 'crs' Parameter Values"
 Registry shall require both "Specification Required" and "IESG
 Approval", as defined in [RFC5226].
 Section 1 contains some text about the motivation for when to
 introduce new 'crs' values.

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:

Mayrhofer & Spanring Standards Track [Page 20] RFC 5870 'geo' URI Scheme June 2010

9.1. Invalid Locations

 The URI syntax (Section 3.3) makes it possible to construct 'geo'
 URIs that don't identify a valid location.  Applications MUST NOT use
 URIs with such values and SHOULD warn the user when such URIs are
 encountered.
 An example of such a URI referring to an invalid location would be
 <geo:94,0> (latitude "beyond" north pole).

9.2. Location Privacy

 A 'geo' URI by itself is just an opaque reference to a physical
 location, expressed by a set of spatial coordinates.  This does not
 fit the "Location Information" definition according to Section 5.2 of
 GEOPRIV Requirements [RFC3693], because there is not necessarily a
 "Device" involved.
 Because there is also no way to specify the identity of a "Target"
 within the confines of a 'geo' URI, it also does not fit the
 specification of a "Location Object" (Section 5.2 of RFC 3693).
 However, if a 'geo' URI is used in a context where it identifies the
 location of a Target, it becomes part of a Location Object and is
 therefore subject to GEOPRIV rules.
 Therefore, when 'geo' URIs are put into such contexts, the privacy
 requirements of RFC 3693 MUST be met.

10. Acknowledgements

 Martin Thomson has provided significant text around the definition of
 the "uncertainty" parameter and the GML mappings.
 The authors further wish to acknowledge the helpful contributions
 from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim
 Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjoern
 Hoehrmann, Alissa Cooper, and Ivan Shmakov.
 Alfred Hoenes has provided an extremely helpful in-depth review of
 the document.

Mayrhofer & Spanring Standards Track [Page 21] RFC 5870 'geo' URI Scheme June 2010

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.
 [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
            Presence Information Data Format Location Object (PIDF-LO)
            Usage Clarification, Considerations, and Recommendations",
            RFC 5491, March 2009.

11.2. Informative References

 [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
            Registration Procedures for New URI Schemes", BCP 35,
            RFC 4395, February 2006.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
            J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
 [WGS84]    National Imagery and Mapping Agency, "Department of
            Defense World Geodetic System 1984, Third Edition",
            NIMA TR8350.2, January 2000.
 [ISO.6709.2008]
            International Organization for Standardization, "Standard
            representation of geographic point location by
            coordinates", ISO Standard 6709, 2008.

Mayrhofer & Spanring Standards Track [Page 22] RFC 5870 'geo' URI Scheme June 2010

Authors' Addresses

 Alexander Mayrhofer
 IPCom GmbH
 Karlsplatz 1/2/9
 Wien  A-1010
 Austria
 Phone: +43 1 5056416 34
 Email: alexander.mayrhofer@ipcom.at
 URI:   http://www.ipcom.at/
 Christian   Spanring
 73 Josephine Ave
 Somerville  02144
 Email: christian@spanring.eu
 URI:   http://www.spanring.eu/

Mayrhofer & Spanring Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5870.txt · Last modified: 2010/06/04 21:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki