Geo URI scheme
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 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>
Coordinate reference systems
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 Washington Monument's location expressed with UTM-zone 18S and its standard ID:
- A geo URI for a hypothetical lunar CRS created in 2011 might be:
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.
Semantics and usual interpretations
This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (May 2019) (Learn how and when to remove this template message)
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 coodinates 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"), and the concept is extend 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 ..." and that "... an <altitude> value of 0 MUST NOT be mistaken to refer to 'ground elevation'".
The "ground elevation" (referred by RFC) at the latitude-longitude point is h, synonymous with "projection in the Terrain surface" or "real altitude of the point", them altitude is synonymous with h. When the position measured at time t in the past has undefined altitude, the RFC says that we can replace it with h (measured after time t), adopting altitude=h implicitly.
A point with a measure "altitude=0" is a point on the surface of the ellipsoid (a measure with h=0 that is not be confused with N=0 nor WD=0) so, a point where ellipsoid and Terrain surfaces coincides.
Geo URI is not about exact abstract positions, strictly it is an location estimate, and we can interpretate it (from RFC 5870 and RFC 5491) as the approximate physical position of an object in the Earth's surface.
The RFC 5870 not formalize the use of the "uncertainty" term. The clues about it comes from citations: 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 this clues, the usual statistical assumptions, and the explicit definitions of the RFC, we obtain the Geo URI's uncertainty mathematical properties:
- uncertainty is symmetric: the RFC is explicit, and we can understand it as valid simplification hypothesis. "The single uncertainty value is applied to all dimensions given in the URI" (section 3.4.3). Results in a spherical volume around the point (or a disk by 2D projection).
By RFC 5491 "locations are expressed as a point (...) and an area or volume of uncertainty around the point".
- Using RFC 5491, we can suppose that "It is RECOMMENDED that uncertainty is expressed at a confidence of 95% or higher". Therefore, the uncertainty is two standard deviations, 2σ, and it is the radius of the disk that represents uncertainty geometrically.
- fixed measure unit: the RFC obligate the use of meters as uncertainty measure units, even when coordinates (CRS) use other (like default that is decimal degrees). It is a semantic and a convertion problem: the
- Gaussian error model: RFC say nothing, we interpreting the phrases "amount of uncertainty in the location" and "the uncertainty with which the identified location of the subject is known", all in the context of the normative reference, RFC 5491 (and the informative references like ISO 6709:2008).
- total uncertainty: it is only one parameter representing "all uncertainty", the uncertainty in the spatial measure and uncertainty about object definition or object's center. It is a sum of random variables. There is no simplification hypothesis defined to reduce it to an one-variable model.
Imagining the location of an ant colony to illustrate:
- the colony is a 3D object at the (exactly) the Terrain surface, so at precise altitude (approximated to a zero uncertainty measure).
- the 3D object has some consensual definition, but it is not precise, so, its uncertainty can not be neglected. This lack of precision can be about the fact that the anthill is hidden under the ground (it is an "estimated object"), or the formal definition of its delimitation, etc. This kind of uncertainty have no correlation with the location (e.g. GPS) uncertainty measure.
- the disk representing the anthill (as uncertainty of the object) is modeled as 2σ to be a 95% of confidence area.
- the point is a GPS location measure, that is, the "center" of the projection of the 3D object in the 2D surface.
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.
- "RFC 5870 - A Uniform Resource Identifier for Geographic Locations (geo URI)". Internet Engineering Task Force. 2010-06-08. Retrieved 9 June 2010.
- "RFC 6350 - vCard Format Specification". Internet Engineering Task Force. 2011-08-11. Retrieved 19 Jun 2012.
- "Android Intents List". google.com. Retrieved 2012-06-19.
- "Geourl.org". Geourl.org. Archived from the original on 2011-12-27. Retrieved 2011-12-24.
- Section 3.4.5 of RFC5870.
- Using RFC 5491, that expressed that "... in theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume" we can use also the concept home range of the ants or the ant's queen, to define the anthill.