A Uniform Resource Identifier for Geographic Locations ('geo' URI)
Extracted elements (29)
The 'crs' extension point is provided primarily to accommodate a future scenario where another CRS replaces WGS-84 as the predominant system, not to support arbitrary use of thousands of CRSes — which would harm interoperability. Use of alternate CRSes is explicitly discouraged in comparison-heavy use cases.
The number of decimal digits in coordinate values MUST NOT be interpreted as indicating a level of accuracy or uncertainty. Uncertainty is expressed only via the explicit 'u' parameter, keeping coordinate precision concerns separate from uncertainty semantics.
The URI scheme is deliberately scoped to the simplest, most common case: a single point in a well-known CRS. More complex geometries (polygons, civic addresses) are explicitly out of scope, prioritizing compactness and broad applicability over expressiveness.
WGS-84 was chosen as the default CRS because GPS devices — anticipated to be a primary data source for 'geo' URI authoring — natively use WGS-84. Many other geographic data formats also use WGS-84, minimizing reprojection errors. The burden of any required spatial transformation is intentionally placed on URI authors rather than consumers.
A 'geo' URI with altitude value 0 MUST NOT be mistaken to mean 'ground elevation'; altitudes are relative to the WGS-84 reference geoid, not Earth's physical surface. A consumer of a URI with undefined altitude MAY assume the location is on Earth's physical surface.
Legacy implementations encountering unknown 'geo' URI parameters can only determine equality if the same set of unknown parameter names appears in both URIs with bitwise-identical (post percent-decode) values; otherwise, the comparison result is undefined. Future parameter designers should account for this when choosing comparison rules.
A URI with an undefined (missing) <coord-c> altitude MUST NOT be considered equal to a URI containing a <coord-c> value, even if all other components are equivalent.
Applications MUST NOT use 'geo' URIs with coordinate values that identify invalid locations (e.g., latitude beyond ±90), and SHOULD warn the user when such URIs are encountered.
Both 'crs' and 'u' parameters MUST NOT appear more than once each. The 'crs' and 'u' parameters MUST appear before any other parameters, and 'crs' MUST be listed before 'u' when both are present.
Case sensitivity of non-numeric parameter values MUST be described in the specification of the respective parameter. For the 'crs' parameter specifically, values are case-insensitive.
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.
Consumers of 'geo' URIs MUST NOT ignore the 'crs' parameter if present, and MUST NOT interpret coordinate sub-components without considering and understanding the 'crs' parameter value, because using the wrong CRS produces entirely invalid location information.
For 'geo' URI comparison, <coord-a>, <coord-b>, <coord-c>, and 'u' values MUST be compared as normalized numbers (mathematically identical) rather than as raw strings, so that '43.10' and '43.1' are treated as equal.
For WGS-84 URI comparison: (1) at poles (latitude ±90), longitude MUST be ignored; (2) a longitude of 180 degrees MUST be considered equal to -180 degrees ('date line' case). Parameter order is not significant for URI comparison.
For WGS-84 URIs where <latitude> is exactly 90 or -90 degrees (the poles), <longitude> SHOULD be set to '0' by authors, but consumers MUST accept any longitude value from -180 to 180 at the poles.
Future specifications introducing non-ASCII parameter values MUST describe internationalization considerations for those parameters and MUST require percent-encoding of non-ASCII values.
'geo' URIs with longitude values outside -180 to 180 decimal degrees or with latitude values outside -90 to 90 degrees MUST be considered invalid.
New 'geo' URI parameters and new values for existing 'Predefined' parameters MUST be registered with IANA. The specification of a parameter MUST fully explain the syntax, intended usage, and semantics to ensure interoperability.
The comma (',') delimiter used to separate coordinate sub-components in the <coordinates> path component MUST NOT be percent-encoded. It is RECOMMENDED that coordinate values, <crslabel>, and <uval> contents are never percent-encoded.
When a 'geo' URI is used in a context where it identifies the location of a Target (thus becoming part of a Location Object), the privacy requirements of RFC 3693 (GEOPRIV Requirements) MUST be met.
When altitude is unknown, the <altitude> component (and the preceding comma) MUST NOT be present in the URI. Unknown altitude MUST NOT be represented by setting <altitude> to '0' or any other arbitrary value.
A 'geo' URI alone does not constitute a 'Location Object' under GEOPRIV (RFC 3693) because it does not identify a Target or Device. However, when used in a context that does identify a Target's location, full GEOPRIV privacy rules apply.
The optional 'crs' parameter identifies the Coordinate Reference System in use. If absent or set to 'wgs84', the URI uses WGS-84 (EPSG 4326 for 2D, EPSG 4979 for 3D). The 'crs' parameter value is case-insensitive; lowercase is preferred.
The optional 'u' parameter expresses location uncertainty in meters. A missing 'u' parameter means uncertainty is unknown or unspecified; a value of zero explicitly indicates a precise point. Zero uncertainty and absent uncertainty are never equivalent.
This document creates the IANA registry "'geo' URI Parameters" for the <parameter> component. Initial entries are 'crs' (Predefined values) and 'u' (Constrained by syntax). Registration policy is Specification Required (with Designated Expert).
This document creates the IANA sub-registry "'geo' URI 'crs' Parameter Values". The initial value is 'wgs84' (mapping to EPSG 4326 and EPSG 4979). Registration policy requires both Specification Required and IESG Approval.
This document registers the 'geo' URI scheme in the IETF part of the URI scheme tree as a permanent scheme, per BCP 115 (RFC 4395). Change control rests with the IETF.
The 'geo' URI syntax permits construction of URIs that do not identify a valid location (e.g., latitude beyond the poles). Applications MUST NOT use such URIs and SHOULD warn users when they are encountered.
The 'geo' URI is defined by ABNF as: geo-URI = geo-scheme ":" geo-path, where geo-path = coordinates p, coordinates = coord-a "," coord-b ["," coord-c], and optional parameters follow as semicolon-delimited key=value pairs. For WGS-84, coord-a is latitude (1-2 digits before decimal), coord-b is longitude (1-3 digits before decimal), and coord-c is altitude in meters.