One document matched: draft-ietf-geopriv-geo-uri-04.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr='pre5378Trust200902' docName='draft-ietf-geopriv-geo-uri-04' >
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc symrefs='yes' ?>
<front>
<title abbrev="'geo' URI Scheme">
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
</title>
<author initials='A.' surname='Mayrhofer' fullname='Alexander Mayrhofer'>
<organization abbrev='nic.at'>
nic.at GmbH
</organization>
<address>
<postal>
<street>Karlsplatz 1/2/9</street>
<city>Wien</city>
<code>A-1010</code>
<country>Austria</country>
</postal>
<phone>+43 1 5056416 34</phone>
<email>alexander.mayrhofer@nic.at</email>
<uri>http://geouri.org/</uri>
</address>
</author>
<author initials='C.' surname='Spanring' fullname='Christian
Spanring'>
<organization abbrev=''></organization>
<address>
<postal>
<street>30 Hancock St</street>
<city>Somerville</city>
<code>02144</code>
<state>Massachusetts</state>
</postal>
<phone>+1 617 863 0360</phone>
<email>christian@spanring.eu</email>
<uri>http://www.spanring.eu/</uri>
</address>
</author>
<date month='November' year='2009' day='09'/>
<area>RAI</area>
<workgroup>GEOPRIV -- Geographic Location/Privacy Working Group</workgroup>
<keyword>geography</keyword>
<keyword>geo</keyword>
<keyword>URI</keyword>
<keyword>scheme</keyword>
<abstract>
<t>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 WGS-84.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>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.
</t>
<t>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 which formerly were
accessible to professionals only have became available to a
wider audience.
</t>
<t>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
a particular location or triggering further services
shouldn't be any harder than clicking on a 'mailto:' link
and writing an email straight away.
</t>
<t>According to <xref target='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), per default the <xref target='WGS84'>World Geodetic System 1984
(WGS-84)</xref>. 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 an 'geo' URI follows:</t>
<vspace blankLines='1'/>
<list style='hanging'>
<t>geo:13.4125,103.8667</t>
</list>
<t>
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.</t>
<t>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.
</t>
<t>
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
interopability). The definition of 'crs' values
beyond the default of "wgs84" is therefore out of scope of
this document.
</t>
<t>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.
</t>
</section>
<section anchor='terminology' title='Terminology'>
<t>Geographic locations in this document are defined using WGS-84 (World Geodetic System 1984), equivalent to the International Association of Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 (3 dimensions). This document does not assign responsibilities for coordinate transformations from and to other Spatial Reference Systems.</t>
<t>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.</t>
<t>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 are signed negative with a leading dash.</t>
<t>
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
<xref target='RFC2119'>RFC 2119</xref>.
</t>
</section>
<section anchor='registration' title="IANA Registration of 'geo' URI Scheme">
<t>This section contains the fields required for the URI scheme
registration, following the guidelines in section 5.4 of
<xref target='RFC4395'/>.
</t>
<section anchor='uriscname' title='URI Scheme Name'>
<t>geo</t>
</section>
<section anchor='uristatus' title='Status'>
<t>permanent</t>
</section>
<section anchor='urisyntax' title='URI Scheme Syntax'>
<t>The syntax of the 'geo' URI scheme is specified below in
<xref target='RFC5234'>Augmented Backus-Naur Form (ABNF)
</xref>:
</t>
<artwork>
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
p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
</artwork>
<t>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 scope of this document. <xref target='ianaparam'/> discusses the IANA registration of such additional parameters and values.
</t>
<t>In case the URI identifies a location in
the default CRS of WGS-84, the <coordinates> sub-components are further
restricted as follows:</t>
<artwork>
coord-a = latitude
coord-b = longitude
coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
</artwork>
</section>
<section anchor='urisemantics' title='URI Scheme Semantics'>
<t>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.
</t>
<section anchor='crsidentification' title='Coordinate Reference System Identification'>
<t>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.
</t>
<t>
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 <coordinates> sub-components
without considering and understanding the 'crs' parameter value.
</t>
<t>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.
</t>
</section>
<section anchor='compdesc' title='Component Description for WGS-84'>
<t>The <latitude>, <longitude> and <altitude>
components as specified in the URI scheme syntax
(<xref target='urisyntax'/>) are to be used as follows:
</t>
<vspace blankLines='1'/>
<list style='symbols'>
<t><latitude> MUST contain the latitude of
the identified location in decimal degrees
in the reference system WGS-84.
</t>
<t><longitude> MUST contain the longitude of
the identified location in decimal degrees
in the reference system WGS-84.
</t>
<t>If present, the OPTIONAL <altitude> MUST contain
the altitude of the identified location in meters in
the reference system WGS-84.
</t>
</list>
<t>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).
</t>
<t>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.
</t>
<t>'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.
</t>
<!-- <t>The number of decimal places indicates the precision of
the value. One degree equals 111,319.45m at the equator
(40,075.004km / 360 degrees). Five decimal places
(0.00001 degree) seem to imply a for civil use
sufficient resolution.
</t> -->
</section>
<section anchor='uncertainty' title="Location Uncertainty">
<t>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.
</t>
<t>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, <uval> MAY be set to zero.
Zero uncertainty and absent uncertainty are never the same thing.
</t>
<t>The single uncertainty value is applied to all dimensions
given in the URI.</t>
<t>Note: The number of digits of the values
in <coordinates> MUST NOT be interpreted
as an indication to uncertainty.</t>
</section>
<section anchor='comparison' title='URI Comparison'>
<t>Two 'geo' URIs are equal when they use the same CRS,
and <coord-a>, <coord-b>, <coord-c>
and 'u' value are mathematically identical (including
absent <uval> meaning undefined 'u' value).</t>
<t>Two URIs use the same CRS if both have the 'crs' parameter
omitted, or both have the same <crslabel>, or
one has the 'crs' parameter omitted while the other URI
specifies the default CRS explicitely with a <crslabel>
value of "wgs84".
</t>
<t>For the default CRS of WGS-84, the following definitions
apply in addition:
<list style='symbols'>
<t>
Where <latitude> of a 'geo' URI is set to either
90 or -90 degrees, <longitude> MUST be ignored
in comparison operations ("poles case"). </t>
<t>A <longitude> of 180 degrees
MUST be considered equal to <longitude> of -180
degrees for the purpose of URI comparison ("date line" case).
</t>
</list>
</t>
<t>
A URI with 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 their 'u' values
are equivalent.
</t>
</section>
<section anchor='altinterpret' title='Interpretation of Undefined Altitude'>
<t>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.
</t>
<t>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".
</t>
</section>
</section>
<section anchor='urienc' title='Encoding Considerations'>
<t>The <coordinates> path component of the 'geo' URI
(see <xref target='urisyntax'/>) uses a comma (",") as the
delimiter for subcomponents. This delimiter MUST NOT be
percent-encoded.
</t>
<t>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.
</t>
<t>Regarding internationalization, the currently specified
components do allow for ASCII characters exclusively,
and therefore don't require 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.
</t>
</section>
<section anchor='uriapps' title='Applications/Protocols that use this URI Scheme'>
<t>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
<xref target='examples'/>.
</t>
</section>
<section anchor='uriinterop' title='Interopability Considerations'>
<t>Like other new URI schemes, the 'geo' URI requires
support in client applications. Users of applications which are
not aware of the 'geo' scheme are likely not able to make direct use
of the information in the URI. However, the simple structure of the
'geo' URI would allow even manual dereference by humans.
</t>
<!-- <t>Malformed and invalid 'geo' URI instances could contain whitespace
and values with leading plus signs ("+"), which is not allowed
according to the ABNF.
Clients MAY, however, try to dereference such URIs after removing
such whitespace and plus signs.</t> -->
<t>
Clients MUST NOT attempt to dereference 'geo' URIs given in an
CRS that is unknown to the client, because doing so would
produce entirely bogus results.
</t>
<t>Authors of 'geo' URIs should carefully check that coordinate
components are set in the right CRS and in
the specified order, since wrong order of those components
(or use of coordinates in a different CRS without transformation)
are commonly observed mistakes producing completely bogus
locations.
</t>
<t>The number of digits in the <coordinates> values MUST NOT
be interpreted as an indication to a certain level of
accuracy or uncertainty.
</t>
</section>
<!-- <section anchor='uriseccons' title='Security Considerations'>
<t>See <xref target='seccons'/> of [insert reference to this document]
</t>
</section> -->
<section anchor='uricontact' title='Contact'>
<list symbol='none'>
<vspace blankLines='1'/>
<t>Alexander Mayrhofer <axelm@nic.at>, <http://geouri.org/></t>
<t>Christian Spanring <christian@spanring.eu></t>
</list>
</section>
<section anchor='urichange' title='Author/Change controller'>
<t>The 'geo' URI scheme is registered under the IETF part of the
URI tree. As such, change control is up to the IETF.
</t>
</section>
<section anchor='uriref' title='References'>
<t>RFC XXXX [change to RFC number once assigned]</t>
</section>
</section>
<section anchor='textparam' title="'geo' URI Parameters Registry">
<t>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 interopability.</t>
<t>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).</t>
<t>The registration of values is REQUIRED for parameters
that accept values from a predefined set.</t>
<t>The specification of a parameter MUST fully explain the syntax,
intended usage and semantics of the parameter. This ensures
interopability between independent implementations.</t>
<t>For parameters that are neither restricted to a set of predefined
values nor of the "flag" type described above, the syntax of
allowed values MUST be described in the specification, for example
by using ABNF.</t>
<t>Documents defining new parameters (or new values for
existing parameters) MUST register them with IANA, as explained in
<xref target='ianaparam'/>.</t>
<t>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:
<vspace blankLines='1'/>
<list style='symbols'>
<t>"No value": The parameter does not accept any values, and
is to be used as a "flag" only.</t>
<t>"Predefined": The parameter does accept values from a
predefined set only, as specified in a RFC or other permanent
and readily available public specification.</t>
<t>"Constrained": The parameter accepts arbitrary values
that are only constrained by a syntax as specified in
a RFC or other permanent and readily available public
specification.</t>
</list>
</t>
<t><xref target='ianaparamcont'/> contains the initial contents of the
Registry.</t>
</section>
<section anchor='uriops' title="URI Operations">
<t>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.
</t>
<t>An application may then use this location information for various
purposes, for example:
<list style='symbols'>
<vspace blankLines='1'/>
<t>A web browser could use that information to open a
mapping service of the user's choice, and display a map of
the location.</t>
<vspace blankLines='1'/>
<t>A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location.
</t>
</list>
</t>
<t>Note that the examples and use cases aboves as well as in
the next section are non-normative, and provided for information
only.</t>
</section> <!-- end of URI Operations section -->
<section anchor='examples' title='Use Cases and Examples'>
<section anchor='plainex' title="Plain 'geo' URI Example">
<t>The following 3-dimensional 'geo' URI example references
to the office location of one of the authors in
Vienna, Austria:
</t>
<t>geo:48.2010,16.3695,183</t>
<t>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.
</t>
</section>
<section anchor='htmlembed' title='Hyperlink'>
<t>'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:
</t>
<artwork>
<p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
</artwork>
<t>A web browser could extract the coordinates from the HTML snippet and offer the user various options (based on
configuration, context), for example:
</t>
<list style='symbols'>
<vspace blankLines='1'/>
<t>Display a small map thumbnail when the mouse pointer hovers over the link.</t>
<vspace blankLines='1'/>
<t>Switch to a mapping service of the user's choice once the
link is selected.</t>
<vspace blankLines='1'/>
<t>Locate nearby resources, for example by comparing the
'geo' URI with locations extracted from GeoRSS
feeds the user has subscribed to.</t>
<vspace blankLines='1'/>
<t>Convert the coordinates to a format suitable for uploading
to a navigation device.</t>
</list>
<t>Note that the URI in this example also makes use of the
explicit specification of the CRS by using the 'crs' parameter.
</t>
</section>
<section anchor='barcode' title="'geo' URI in 2-dimensional barcode">
<t>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:
</t>
<list style='numbers'>
<vspace blankLines='1'/>
<t>User identifies such a barcode on a flyer and uses the camera
on his mobile phone to photograph and decode the barcode.</t>
<vspace blankLines='1'/>
<t>The mobile phone dereferences the 'geo' URI, and offers
the user to calculate a navigation route to the identified
location.</t>
<vspace blankLines='1'/>
<t>Using the builtin GPS receiver, the user follows the
navgiation
instructions to reach the location.</t>
</list>
</section>
</section> <!-- end of Examples section -->
<section anchor='gmlconversion' title='GML Mappings'>
<t>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 transform 'geo' URIs
from and to GML fragments. The instructions in this
section are not normative.
</t>
<t>
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.
</t>
<t>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.
</t>
<t>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.
</t>
<section anchor='2dpoint' title="2D GML 'Point'">
<t>A 2D GML <xref target="RFC5491">'Point'</xref> 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.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%
]]></artwork></figure>
<figure><preamble>GML fragment:</preamble>
<artwork><![CDATA[
<Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
]]></artwork></figure>
<t>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.
</t>
</section>
<section title="3D GML 'Point'">
<t>A 3D GML <xref target="RFC5491">'Point'</xref> 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.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%,%alt%
]]></artwork></figure>
<figure><preamble>GML fragment:</preamble>
<artwork><![CDATA[
<Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
]]></artwork></figure>
</section>
<section title="GML 'Circle'">
<t>A GML <xref target="RFC5491">'Circle'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%;u=%unc%
]]></artwork></figure>
<figure><preamble>GML fragment:</preamble>
<artwork><![CDATA[
<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>
]]></artwork></figure>
</section>
<section title="GML 'Sphere'">
<t>A GML <xref target="RFC5491">'sphere'</xref> is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
geo:%lat%,%lon%,%alt%;u=%unc%
]]></artwork></figure>
<figure><preamble>GML fragment:</preamble>
<artwork><![CDATA[
<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>
]]></artwork></figure>
</section>
</section> <!-- end of mapping section -->
<section anchor='ianacons' title='IANA Considerations'>
<section anchor='ianauri' title="'geo' URI Scheme">
<t>This document requests assignment of the 'geo' URI scheme
in the IETF part of the URI scheme tree, according to the
guidelines in <xref target='RFC4395'>BCP 115 (RFC 4395)</xref>.
The definitions required
for the assignment are contained in <xref target='registration'/>.
</t>
</section>
<section anchor='ianaparam' title='URI Parameter Registry'>
<t>This document creates a new IANA Registry named "'geo' URI
Parameters", according to the information in <xref target='textparam'/> and the definition in this section.</t>
<section anchor='ianaparamcont' title='Registry Contents'>
<t>When registering a new 'geo' URI Parameter, the following
information MUST be provided:</t>
<vspace blankLines='1'/>
<list style='symbols'>
<t>Name of the Parameter.</t>
<t>Whether the Parameter accepts no value ("No value"),
values from a predefined set ("Predefined"),
or values constrained by a syntax only ("Constrained").</t>
<t>Reference to the RFC or other permanent and readily
available public specification defining the parameters and
the new values.</t>
</list>
<t>Unless specific instructions exists 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:
</t>
<vspace blankLines='1'/>
<list style='symbols'>
<t>Name of the Parameter.</t>
<t>Reference to the RFC or other permanent and readily
available public specification defining the new values.</t>
</list>
<t>The following table provides the initial values for this
registry:</t>
<artwork>
Parameter Name Value Restriction Reference(s)
----------------------------------------------------------
crs Predefined [RFCxxxx]
u Constrained [RFCxxxx]
</artwork>
<t>[Note to RFC Editor: Replace RFCxxxx with reference to this
document]</t>
</section>
<section anchor='ianaregpol' title='Registration Policy'>
<t>The Registration Policy for 'geo' URI Parameters and
their value definitions shall be "Specification Required,
Designated Expert", as defined in <xref target='RFC5226'/>.</t>
</section>
</section>
<section anchor='crsregistry' title="Sub-Registry for 'crs' Parameter">
<t>This document creates a new IANA Sub-registry named "'geo' URI 'crs' Parameter Values", based on the Registry specified in <xref target='ianaparam'/> and the information in this section and <xref target='textparam'/>. The syntax
of the 'crs' parameter is constrained by the ABNF given in
<xref target='urisyntax'/>.
</t>
<section anchor='crscontents' title='Registry Contents'>
<t>When registering a new value for the 'crs' parameter, the
following information MUST be provided:
</t>
<vspace blankLines='1'/>
<list style='symbols'>
<t>Value of the parameter.</t>
<t>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.
</t>
<t>Reference to the definition of the CRS itself, preferably
as well known URNs (if available). Note that different URNs
may exist for the 2-dimensional and 3-dimensional case.</t>
</list>
<t>The following table provides the initial values for this
registry:</t>
<artwork>
crs Value Reference(s) CRS definition(s)
-----------------------------------------------------------
wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326
urn:ogc:def:crs:EPSG::4979
</artwork>
<t>[Note to RFC Editor: Replace RFCxxxx with reference to this
document]</t>
</section>
<section anchor='crsregpolicy' title='Registration Policy'>
<t>The registration policy for the "'geo' URI 'crs' Parameter Values"
Registry shall be "Specification Required, IESG Approval" as defined
in <xref target='RFC5226'/>.</t>
<t><xref target='intro'/> contains some text about the motivation
when to introduce new 'crs' values.</t>
</section>
</section>
</section>
<section anchor='seccons' title='Security Considerations'>
<t>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:
</t>
<section anchor='invalidloc' title='Invalid Locations'>
<t>The <xref target='urisyntax'>URI syntax</xref>
makes it possible to construct 'geo' URIs which don't
identify a valid location. Applications MUST NOT use
URIs with such values, and SHOULD warn the user when such
URIs are encountered.
</t>
<t>An example of such an URI referring to an invalid location
would be <geo:94,0> (latitude "beyond" north pole).
</t>
</section>
<section anchor='locprivacy' title='Location Privacy'>
<t>A 'geo' URI by itself is just an opaque reference to a
physical location, expressed by a set of spatial oordinates. This
does not fit the "Location Information" definition according to
Section 5.2 of <xref target='RFC3693'>GEOPRIV Requirements</xref>,
because there is not necessarily a "Device" involved.
</t>
<t>
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 an "Location Object" (Section 5.2 of RFC 3693).
</t>
<t>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.
</t>
<t>Therefore, when 'geo' URIs are put into such contexts, the
privacy requirements of RFC 3693 MUST be met.
</t>
</section>
</section>
<section anchor='ack' title='Acknowledgements'>
<t>Martin Thomson has provided significant text around the
definition of the "uncertainty" parameter and the GML mappings.
</t>
<t>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, Bjorn Hoehrmann,
Alissa Cooper and Ivan Shmakov.
</t>
<t>Alfred Hoenes has provided an extremely helpful in-depth
review of the document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.RFC.5491" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.4395" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.3693" ?>
<?rfc include="reference.WGS84" ?>
</references>
<section anchor='appendix_changelog' title='Change Log'>
<t>[Note to editors: This section is to be removed before publication - XML source available on request]
</t>
<t>draft-ietf-geopriv-geo-uri-04
<list style='symbols'>
<t>Added "crs" URI parameter registry</t>
<t>Added example URI to Introduction</t>
<t>Changed quoting of parameters according to Alfred Hoenes' comments</t>
</list>
</t>
<t>draft-ietf-geopriv-geo-uri-03
<list style='symbols'>
<t>Updated privacy considerations section as per Alissa's comments</t>
<t>Added text on uncertainty applied to all given dimensions</t>
<t>various editorial changes</t>
<t>Changed ABNF to reflect order of parameters (CRS first, then U, then others</t>
</list>
</t>
<t>draft-ietf-geopriv-geo-uri-02
<list style='symbols'>
<t>Added IANA registry for 'geo' URI Parameters and values</t>
<t>Moved change log to appendix</t>
<t>Added "u" parameter to ABNF, restructred ABNF slightly</t>
<t>Added new section describing uncertainty</t>
<t>Changed mapping examples, added some for uncertainty</t>
<t>Added text that number of digits shouldn't be confused
with uncertainty or accuracy</t>
<t>marked GML mappings as non-normative based on URI expert
review advice</t>
<t>added internationalization consideration section</t>
<t>various other changes based on Expert Review</t>
</list>
</t>
<t>draft-ietf-geopriv-geo-uri-01
<list style='symbols'>
<t>added parameters to ABNF</t>
<t>added optional 'crs' parameter to allow future use of other CRSes</t>
<t>Many other changes to not preclude the future specification of
other CRSes.</t>
<t>some typos fixes - credits Bill McQuillan</t>
</list>
</t>
<t>draft-ietf-geopriv-geo-uri-00
<list style='symbols'>
<t>submitted as WG item</t>
<t>changed IPR text because of text used from RFC 4395</t>
<t>added considerations for comparing +180/-180 longitude URIs</t>
<t>some editorial changes</t>
</list>
</t>
<t>draft-mayrhofer-geopriv-geo-uri-01
<list style='symbols'>
<t>added terminology text about WGS-84 (credits Carl Reed)</t>
<t>removed "resolution" / "uncertainty" text</t>
<t>added considerations regarding poles</t>
<t>added text about invalid URIs</t>
</list>
</t>
<t>draft-mayrhofer-geopriv-geo-uri-00
<list style='symbols'>
<t>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.
</t>
<t>Added GML mapping section</t>
</list>
</t>
<t>draft-mayrhofer-geo-uri-01
<list style='symbols'>
<t>removed parameters</t>
</list>
</t>
<t>draft-mayrhofer-geo-uri-00
<list style='symbols'>
<t>initial draft</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:45:19 |