The geo URI scheme is a Uniform Resource Identifier (URI) scheme defined by the Internet Engineering Task Force's RFC 5870 (published 8 June 2010) as:
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 current revision of the vCard specification supports geo URIs in a vCard's "GEO" property, and the GeoSMS standard uses geo URIs for geotagging SMS messages. Android based devices support geo URIs, although that implementation is based on a draft revision of the specification, and supports a different set of URI parameters and query strings.
A geo URI is not to be confused with the former website of GeoURL (which had implemented ICBM addresses).
A simple geo URI might look like:
where the two numerical values represent latitude and longitude respectively, and are separated by a comma. They are coordinates of a horizontal grid (2D). If a third comma-separated value is present, it represents altitude; so, coordinates of a 3D grid. Coordinates in the Southern and Western hemispheres as well as altitudes below the coordinate reference system (depths) are signed negative with a leading dash.
The geo URI also allows for an optional "uncertainty" value, separated by a semicolon, representing the uncertainty of the location in meters, and is described using the "u" URI parameter. A geo URI with an uncertainty parameter looks as follows:
A geo URI may, for example, be included on a web page, as HTML:
<a href="geo:37.786971,-122.399677;u=35">Wikimedia Headquarters</a>
so that a geo URI-aware user agent such as a web browser could launch the user's chosen mapping service; or it could be used in an Atom feed or other XML file.
The values of the coordinates only make sense when a coordinate reference system (CRS) is specified. The default CRS is the World Geodetic System 1984 (WGS-84), and it is not recommended to use any other:
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 only justified use of other CRS today is, perhaps, to preserve projection in large-scale maps, as local UTM, or for non-terrestrial coordinates such as those on the Moon or Mars. The syntax and semantic of the CRS parameter, separated by a semicolon, is described at section 8.3 of RFC 5870. Examples:
The order in which the semicolon-separated parameters occur is partially significant. Whilst the labeltext parameter and future parameters may be given in any order, the
crs and the
u parameters must come first. If both are used, the
crs must precede the
u. All parameters are case-insensitive, so, imagining a future new parameter
mapcolors, it can be ignored by simpler applications, and the above example is exactly equivalent to:
Being in doubt, remember that use of the lowercase representation of parameter names (
mapcolors) is preferred.
The Geo URI scheme semantics, expressed in the section 3.4 of the RFC 5870, is not explicit about some mathematical assumptions, so it is open to interpretation. After ~10 years of its publication, there are some consensual or "most frequently used" assumptions.
The syntax of the Geo UI defines coordinates as
coordinates = coord-a "," coord-b [ "," coord-c ], where
coord-c is optional. The semantic of
coord-c for WGS-84 is altitude (specifically the "ground elevation", relative to the current geoid – Earth Gravitational Model – attached to WGS84), and the concept is extended for other coordinates (of non-default CRS).
The RFC explains that "... undefined <altitude> MAY assume that the URI refers to the respective location on Earth's physical surface." However, "... an <altitude> value of 0 MUST NOT be mistaken to refer to 'ground elevation'".
In other words, when an altitude is defined, the measurement is done relative to the geoid (#5; black line in the image), a surface defined by Earth's gravity approximating the mean sea level. When it is undefined, the elevation is assumed to be the altitude of the latitude-longitude point, that is its height (or negative depth) relative to the geoid (i.e. "ground elevation"). A point with a measure "altitude=0" is, however, not to be confused with an undefined value: it refers to an altitude of 0 meters above the geoid.
The use of a geoid stands in contrast to GeoJSON, which uses direct ellipsoid height.
Remembering the example above,
u=35 part informs the uncertainty. As will be showed, geometrically the uncertainty is a disc of radius
u in turn of the point of the geo URI.
Geo URI is not about exact abstract positions, strictly it is a location estimate, and we can interpret it (from RFC 5870 and RFC 5491) as the approximate physical position of an object in the Earth's surface.
The RFC 5870 does not formalize the use of the "uncertainty" term. So, in a coarse-statistical or any non-statistical numerical analysis, the GeoURI uncertainty is a condition number. The statistical meaning is implicit, come from the references of the RFC: the only normative reference with something about uncertainty is the RFC 5491 (section 5). The main informative reference, ISO 6709:2008, not use the term "uncertainty", but use the terms "accuracy" and "precision", which are uncertainty facets and can be interpreted in accordance with ISO 5725-1 (illustrated).
Putting all together, adopting these clues, the usual statistical assumptions, and the explicit definitions of the RFC, we obtain the Geo URI's uncertainty mathematical properties:
Imagining the location of an ant colony to illustrate:
The total uncertainty is the sum of GPS error and object-definition error. The latitude and longitude GPS errors need to be simplified (to a disk) and converted into meters. If the errors were inferred from a different model, they need to be converted to the Gaussian model.
Some vendors, such as Android OS, have adopted extensions to the "geo" URI scheme:
Google Maps adopts an unconventional approach to displaying the points: it shows the map for, but does not display a map pin, when a location is given in the standard way. A pin only shows up when given as the query. In other words, to show a pin at the Wikimedia Foundation office, one should not use
GeoURL is a location-to-URL reverse directory. This will allow you to find URLs by their proximity to a given location. Find your neighbor's blog, perhaps, or the web page of the restaurants near you. GeoURL is listing 9,601,000 sites. Add yourself to the database.