Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 5870 IPCom
Category: Standards Track C. Spanring
ISSN: 2070-1721 June 2010
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)
地理位置的统一资源标识符（“地理”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).
本文档使用“geo”方案名称为地理位置指定统一资源标识符（URI）。“geo”URI以紧凑、简单、易读且与协议无关的方式在二维或三维坐标系中标识物理位置。使用的默认坐标参考系是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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5870.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
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
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.
“地理”URI方案是朝着这一方向迈出的另一步，旨在促进、支持和标准化地理空间服务和应用程序中的位置识别问题。访问特定位置的信息或触发进一步的服务不应该比点击“mailto:”链接并直接写一封电子邮件更难。
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:
根据[RFC3986]，统一资源标识符（URI）是“识别抽象或物理资源的紧凑字符序列”。本文件中定义的“geo”URI方案确定了坐标参考系（CRS）中的地理位置（物理资源），默认情况下，坐标参考系为1984年世界大地测量系统（WGS-84）[WGS84]。该方案提供位置空间坐标的二维或三维文本表示（WGS-84默认CRS的纬度、经度和可选高度）。这种“geo”URI的示例如下：
geo:13.4125,103.8667
地理位置：13.4125103.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.
此类URI独立于特定的协议、应用程序或数据格式，并且可以在支持包含任意URI的任何其他协议或数据格式中使用。
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.
为了可用性，URI方案的定义严格地集中在空间位置的最简单、也是最常见的表示形式上——众所周知的CRS中的一个点。civic Addresss描述的更复杂的几何图形或位置超出了本文件的范围。
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.
以下描述的可选“crs”URI参数可由未来规范用于定义除WGS-84以外的crs的使用。这主要是为了处理另一个CRS取代WGS-84作为主要使用的CRS的情况，而不是允许对URI任意使用数千个CRS（这显然会影响互操作性）。因此，超出默认值“wgs84”的“crs”值定义不在本文件范围内。
This specification discourages use of alternate CRSes in use cases where comparison is an important function.
本规范不鼓励在比较是重要功能的用例中使用备用CRSE。
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.
注：选择WGS-84作为默认CRS是基于使用WGS-84参考系统的全球定位系统（GPS）设备的广泛可用性。预计此类设备将作为编写“地理”URI的主要数据源之一，因此URI方案采用本地GPS参考系统。此外，用于表示地理位置的许多其他数据格式使用WGS-84参考系统，这使得此类数据格式之间的转换不易出错（不涉及重新投影）。人们还认为，潜在需要的空间转换的负担应该由“geo”URI实例的作者而不是使用者承担。
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.
由于其相似的结构，“geo”URI实例也可以映射到地理点位置的某些ISO 6709[ISO.6709.2008]字符串表示形式。
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.
本文件中的地理位置使用WGS-84（1984年世界大地测量系统）定义，该系统相当于国际石油天然气生产商协会（OGP）测量和定位委员会EPSG（欧洲石油测量集团）代码4326（2维）和4979（3维）。本文件不指定从其他空间参照系到其他空间参照系的坐标转换责任。
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.
二维WGS-84坐标值在此处表示为逗号分隔的纬度/经度对，以十进制度数（未投影）测量。三维WGS-84坐标值在此处表示为将逗号分隔的高度值（以米为单位）附加到这些坐标对上。
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.
纬度从-90到90，经度从-180到180。南半球和西半球的坐标以及WGS-84参考大地水准面（深度）以下的高度用一个前导破折号表示为负数。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section contains the fields required for the URI scheme registration, following the guidelines in Section 5.4 of [RFC4395].
本节包含URI方案注册所需的字段，遵循[RFC4395]第5.4节中的指南。
geo
地理位置
permanent
永久的
The syntax of the 'geo' URI scheme is specified below in Augmented Backus-Naur Form (ABNF) [RFC5234]:
“geo”URI方案的语法如下所示，采用增广的Backus Naur格式（ABNF）[RFC5234]：
geo-URI = geo-scheme ":" geo-path geo-scheme = "geo" geo-path = coordinates p coordinates = coord-a "," coord-b [ "," coord-c ]
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
坐标-a=num坐标-b=num坐标-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
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
labeltext = 1*( alphanum / "-" )
pnum = 1*DIGIT [ "." 1*DIGIT ]
num = [ "-" ] pnum
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
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.
参数名称不区分大小写，但首选使用小写表示。非数字参数值的区分大小写必须在相应参数的规范中说明。对于“crs”参数，值不区分大小写，首选小写。
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.
“crs”和“u”参数不得出现一次以上。“crs”和“u”参数必须在未来扩展中可能定义的任何其他参数之前给出。如果同时使用“crs”和“u”，则必须首先给出“crs”参数。超出默认值“wgs84”的其他参数和<crslabel>值的定义不在本文件范围内。第8.2节讨论了此类附加参数和值的IANA注册。
The value of "-0" for <num> is allowed and is identical to "0".
<num>的“-0”值是允许的，并且与“0”相同。
In case the URI identifies a location in the default CRS of WGS-84, the <coordinates> sub-components are further restricted as follows:
如果URI在WGS-84的默认CRS中标识位置，<coordinates>子组件进一步限制如下：
coord-a = latitude coord-b = longitude coord-c = altitude
坐标-a=纬度坐标-b=经度坐标-c=高度
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
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.
“geo”URI中包含的数据标识物理资源：由地理坐标和URI中编码的CRS标识的空间位置。
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.
<coordinates>的语义取决于URI的CRS。CRS本身由可选的“CRS”参数标识。如果“CRS”参数缺失或包含“wgs84”值，URI实例将使用默认的WGS-84 CRS。其他<crslabel>值目前尚未定义，但可能由将来的文档指定。
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
在错误的CRS中解释坐标会产生无效的位置信息。因此，“geo”URI的使用者不得忽略“crs”参数（如果给定），也不得解释
<coordinates> sub-components without considering and understanding the 'crs' parameter value.
<coordinates>子组件，而不考虑和理解“crs”参数值。
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.
以下部件说明仅涉及默认CRS（WGS-84）的使用。指定其他“crs”参数值的未来文件必须为所述crs中的<coordinates>子组件提供类似的描述。
The <latitude>, <longitude>, and <altitude> components as specified in the URI scheme syntax (Section 3.3) are to be used as follows:
URI方案语法（第3.3节）中指定的<latitude>、<longitude>和<altitude>组件将按如下方式使用：
o <latitude> MUST contain the latitude of the identified location in decimal degrees in the reference system WGS-84.
o <纬度>必须包含参考系统WGS-84中以十进制度数表示的已识别位置的纬度。
o <longitude> MUST contain the longitude of the identified location in decimal degrees in the reference system WGS-84.
o <经度>必须包含参考系统WGS-84中以十进制度数表示的已识别位置的经度。
o If present, the OPTIONAL <altitude> MUST contain the altitude of the identified location in meters in the reference system WGS-84.
o 如果存在，可选的<altitude>必须包含参考系统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).
如果位置的海拔高度未知，则URI中不得出现<altitude>（以及前面的逗号）。具体而言，未知高度不得通过将<高度>设置为“0”（或任何其他任意值）来表示。
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.
反映极点的坐标值（<纬度>设置为-90或90度）的<经度>应设置为“0”，尽管“地理”URI的使用者必须接受具有-180到180之间任何经度值的URI。
'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.
经度值超出-180到180十进制度数范围或纬度值超出-90到90度范围的“geo”URI必须视为无效。
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.
“u”（“不确定度”）参数以米为单位表示位置的不确定度。当“地理”URI用于识别特定对象的位置时，<uval>表示已知对象的已识别位置的不确定性。
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,
“u”参数是可选的，只能出现一次。如果未指定，则表示不确定性未知或未指定。如果目的是指示空间中的特定点，
<uval> MAY be set to zero. Zero uncertainty and absent uncertainty are never the same thing.
<uval>可以设置为零。零不确定性和无不确定性从来不是一回事。
The single uncertainty value is applied to all dimensions given in the URI.
单个不确定性值应用于URI中给定的所有维度。
Note: The number of digits of the values in <coordinates> MUST NOT be interpreted as an indication to the level of uncertainty.
注：<坐标>中数值的位数不得解释为不确定度水平的指示。
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.
URI比较旨在确定两个URI字符串是否相等，并标识相同的资源（而不是比较资源本身）。因此，比较两个“地理”URI不会比较空间对象，而只会比较标识这些对象的字符串（URI）。
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).
下面使用的术语“数学上相同”指定必须将URI的某些组件作为标准化数字而不是字符串进行比较，以说明相同数字的字符串表示形式的多样性（例如，字符串“43.10”和“43.1”不同，但表示相同的数字）。
Two 'geo' URIs are equal only if they fulfill all of the following general comparison rules:
两个“geo”URI只有满足以下所有一般比较规则时才相等：
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 两个URI使用相同的CRS，这意味着要么两者都省略了“CRS”参数，要么两者都具有相同的<crslabel>值，或者一个URI省略了“CRS”参数，而另一个URI使用<crslabel>值“wgs84”显式指定默认CRS。
o Their <coord-a>, <coord-b>, <coord-c> and 'u' values are mathematically identical (including absent <uval> meaning undefined 'u' value).
o 它们的<coord-a>、<coord-b>、<coord-c>和“u”值在数学上是相同的（包括缺少<uval>表示未定义的“u”值）。
o Their sets of other parameters are equal, with comparison operations applied on each parameter as described in its respective specification.
o 它们的其他参数集是相等的，对每个参数应用比较操作，如各自规范中所述。
Parameter order is not significant for URI comparison.
参数顺序对于URI比较不重要。
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:
由于新参数可能会随着时间的推移而注册，“geo”URI的旧实现可能会遇到未知参数。在这种情况下，以下规则适用：
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 只有当同一组未知参数名称出现在每个URI中，并且它们的值在百分比解码后按位相同时，两个具有未知参数的“geo”URI才是等效的。
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).
o 否则，各个uri的比较操作是未定义的（因为遗留实现无法知道这些参数的比较规则）。
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.
具有未定义（缺少）<coord-c>（高度）值的URI不得视为等于包含<coord-c>的URI，即使剩余的<coord-A>、<coord-b>和“u”值是等效的。
For the default CRS of WGS-84, the following comparison rules apply additionally:
对于WGS-84的默认CRS，以下比较规则还适用：
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 如果“geo”URI的<latitude>设置为90度或-90度，则在比较操作中必须忽略<longitude>（“极点情况”）。
o A <longitude> of 180 degrees MUST be considered equal to <longitude> of -180 degrees for the purpose of URI comparison ("date line" case).
o 为了进行URI比较（“日期行”情况），180度的<经度>必须视为等于-180度的<经度>。
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.
WGS-84 CRS中未定义<altitude>的“geo”URI的使用者可以假设URI指的是给定纬度和经度下地球物理表面上的相应位置。
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".
然而，如上所述，高度是相对于WGS-84参考大地水准面而不是地球表面的。因此，不得将<海拔>值0误认为是“地面高程”。
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.
“geo”URI的路径组件（参见第3.3节）使用逗号（“，”）作为子组件的分隔符。此分隔符不能采用百分比编码。
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.
为了便于阅读，建议不要对<coord-a>、<coord-b>和<coord-c>以及<crslab>和<uval>的内容进行百分比编码。
Regarding internationalization, the currently specified components do allow for ASCII characters exclusively, and therefore don't require
关于国际化，当前指定的组件只允许ASCII字符，因此不需要
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.
国际化。其他参数的未来规范可能允许引入非ASCII值。此类规范必须描述这些参数及其值的国际化注意事项，并且必须要求对非ASCII值进行百分比编码。
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.
与许多其他URI方案定义一样，“geo”URI提供独立于特定应用程序或协议的资源标识。潜在协议映射和用例的示例可以在第6节中找到。
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.
与其他新的URI方案一样，“geo”URI需要客户端应用程序中的支持。不知道“geo”方案的应用程序的用户可能无法直接使用URI中的信息。但是，客户机可以通过传递“geo”uri间接使用，即使不了解方案的格式和语义。此外，“geo”uri的简单结构甚至允许人工取消引用。
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.
客户不得尝试取消引用客户不知道的CRS中给出的“geo”URI，因为这样做会产生完全虚假的结果。
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.
“geo”URI的作者应仔细检查坐标组件是否设置在正确的CRS中以及是否按指定顺序设置，因为这些组件的错误顺序（或在不同的CRS中使用坐标而不进行转换）通常是观察到的错误，从而产生完全虚假的位置。
The number of digits in the <coordinates> values MUST NOT be interpreted as an indication of a certain level of accuracy or uncertainty.
<coordinates>值中的位数不得解释为某一精度或不确定性水平的指示。
See Section 9 of RFC 5870.
见RFC 5870第9节。
Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
Christian Spanring <christian@spanring.eu>
Christian Spanring <christian@spanring.eu>
The 'geo' URI scheme is registered under the IETF part of the URI tree. As such, change control is up to the IETF.
“geo”URI方案在URI树的IETF部分下注册。因此，变更控制由IETF决定。
RFC 5870
RFC 5870
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.
此规范为URI的<parameter>组件创建一个名为“'geo'URI Parameters”的新IANA注册表。“geo”URI的参数和这些参数的值必须向IANA注册，以防止命名空间冲突并提供互操作性。
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.
对于既不限于一组预定义值也不限于上述“标志”类型的参数，必须在规范中描述允许值的语法，例如使用ABNF。
Documents defining new parameters (or new values for existing parameters) MUST register them with IANA, as explained in Section 8.2.
定义新参数（或现有参数的新值）的文件必须向IANA注册，如第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:
“geo”URI参数注册表包含一个名为“Value Restriction”的列，该列描述参数是否接受值，以及值是否限制为预定义的集。该列接受以下值：
o "No value": The parameter does not accept any values and is to be used as a "flag" only.
o “无值”：参数不接受任何值，仅用作“标志”。
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 “预定义”：该参数仅接受RFC或其他永久和现成的公共规范中指定的预定义集的值。
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.
o “constrated”：该参数接受仅受RFC或其他永久性且随时可用的公共规范中指定的语法约束的任意值。
Section 8.2.1 contains the initial contents of the Registry.
第8.2.1节包含注册表的初始内容。
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.
目前，只定义了对“geo”URI的一个操作-位置解引用：在该操作中，客户端通过从URI路径组件<geo path>提取地理坐标来解引用URI。这些坐标（以及<uval>中的不确定性值）的进一步使用取决于处理URI的应用程序，并且可能取决于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 web浏览器可以使用该信息打开用户选择的地图服务，并显示位置地图。
o A navigational device such as a Global Positioning System (GPS) receiver could offer the user the ability to start navigation to the location.
o 诸如全球定位系统（GPS）接收器之类的导航设备可以为用户提供开始导航到该位置的能力。
Note that the examples and use cases above as well as in the next section are non-normative, and are provided for information only.
请注意，上面以及下一节中的示例和用例都是非规范性的，仅供参考。
The following 3-dimensional 'geo' URI example references to the office location of one of the authors in Vienna, Austria:
以下三维“geo”URI示例引用了其中一位作者在奥地利维也纳的办公地点：
geo:48.2010,16.3695,183
地理位置：48.2010,16.3695183
Resolution of the URI returns the following information:
URI解析返回以下信息：
o The 'crs' parameter is not given in the URI, which means that the URI uses the default CRS of WGS-84.
o URI中没有给出“crs”参数，这意味着URI使用WGS-84的默认crs。
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.
o URI包含<coord-c>，因此是三维的，因此使用“urn:ogc:def:crs:EPSG:：4979”作为WGS-84 crs标识符。
o The <coord-a> value (latitude in WGS-84) is set to '48.2010' decimal degrees.
o <coord-a>值（WGS-84中的纬度）设置为“48.2010”十进制度数。
o The <coord-b> value (longitude in WGS-84) is set to '16.3695' decimal degrees.
o <coord-b>值（WGS-84中的经度）设置为“16.3695”十进制度数。
o The <coord-c> value (altitude in WGS-84) is set to 183 meters.
o <coord-c>值（WGS-84中的高度）设置为183米。
o Uncertainty is undefined.
o 不确定性是不确定的。
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.
用户可以将从该URI提取的数据输入电子导航设备，甚至可以使用它在纸质地图上定位已识别的位置。
'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:
“geo”URI（与任何其他URI方案一样）也可以作为超链接嵌入到网页中。具有此类超链接的超文本标记语言（HTML）代码段可能如下所示：
<p>one of Vienna's popular sights is the <a href='geo:48.198634,16.371648;crs=wgs84;u=40'>Karlskirche</a>.
<p>维也纳最受欢迎的景点之一是<a href='geo:48.198634,16.371648；crs=wgs84；u=40'>Karlskirche</a>。
Resolution of the URI returns the following information:
URI解析返回以下信息：
o The 'crs' is given in the URI and sets the CRS used in the URI to WGS-84 explicitly.
o “crs”在URI中给出，并将URI中使用的crs显式设置为WGS-84。
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 URI确实省略了<coord-c>，因此是二维的，因此使用“urn:ogc:def:crs:EPSG:：4326”作为WGS-84 crs标识符。
o The <coord-a> value (latitude in WGS-84) is set to '48.198634' decimal degrees.
o <coord-a>值（WGS-84中的纬度）设置为“48.198634”十进制度数。
o The <coord-b> value (longitude in WGS-84) is set to '16.371648' decimal degrees.
o <coord-b>值（WGS-84中的经度）设置为“16.371648”十进制度数。
o The <coord-c> (altitude) value is undefined; therefore, the client MAY assume the identified location to be on Earth's physical surface.
o <coord-c>（高度）值未定义；因此，客户可以假定已识别的位置位于地球的物理表面上。
o The 'u' parameter is included in the URI, setting uncertainty to 40 meters.
o “u”参数包含在URI中，将不确定性设置为40米。
A web browser could use this information from the HTML snippet, and offer the user various options (based on configuration, context), for example:
web浏览器可以使用HTML代码段中的这些信息，并为用户提供各种选项（基于配置、上下文），例如：
o Display a small map thumbnail when the mouse pointer hovers over the link.
o 当鼠标指针悬停在链接上时，显示一个小地图缩略图。
o Switch to a mapping service of the user's choice once the link is selected.
o 选择链接后，切换到用户选择的映射服务。
o Locate nearby resources, for example by comparing the 'geo' URI with locations extracted from GeoRSS feeds to which the user has subscribed.
o 定位附近的资源，例如通过将“geo”URI与从用户订阅的GeoRSS提要中提取的位置进行比较。
o Convert the coordinates to a format suitable for uploading to a navigation device.
o 将坐标转换为适合上传至导航设备的格式。
Note that the URI in this example also makes use of the explicit specification of the CRS by using the 'crs' parameter.
注意，本例中的URI还通过使用“CRS”参数来使用CRS的显式规范。
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:
由于它的长度很短，“geo”URI可以很容易地用二维条形码编码。这种条形码可以打印在名片、传单和纸质地图上，随后被移动设备使用，例如：
1. User identifies such a barcode on a flyer and uses the camera on his mobile phone to photograph and decode the barcode.
1. 用户在传单上识别这样的条形码，并使用手机上的摄像头拍摄和解码条形码。
2. The mobile phone dereferences the 'geo' URI, and offers the user the ability to calculate a navigation route to the identified location.
2. 移动电话取消对“geo”URI的引用，并为用户提供计算到所识别位置的导航路线的能力。
3. Using the builtin GPS receiver, the user follows the navigation instructions to reach the location.
3. 使用内置GPS接收器，用户按照导航说明到达该位置。
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.
本节提供URI比较的示例。请注意，本节中的未知参数“foo”和“bar”以及未注册的“crs”值仅用于说明目的，其包含在以下示例中并不构成任何正式的参数定义或注册请求。
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.
o 两个URI<geo:90，-22.43；crs=WGS84>和<geo:90,46>是相等的，因为两者使用相同的crs，即使经度值不同，两者都反映了北极的位置（WGS-84的特殊“极点”规则适用-经度将被忽略）。请注意，“crs”参数值不区分大小写。
o The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal, because their coordinate components are mathematically identical.
o uri<geo:22.300-118.44>和<geo:22.3-118.4400>是相等的，因为它们的坐标分量在数学上是相同的。
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 <geo:66,30；u=6.500；FOo=这个%2dthat>和<geo:66.0,30；u=6.5；foo=这一>相同，因为未知参数“foo”的值在百分比解码后按位相同；参数名称不区分大小写，坐标和不确定性在数学上完全相同。
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 <geo:70,20的比较运算；foo=1.00；条形=白色>和<geo:70,20；foo=1；传统实现中的bar=white>未定义，因为“foo”的规范化规则未知，因此该实现无法识别“1.00”是否与“foo”参数的“1”相同。
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 比较<geo:47,11；foo=蓝色；条形=白色>和<geo:47,11；条形=白色；foo=blue>返回true，因为参数顺序在比较操作中无关紧要。
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.
o <geo:22,0的比较运算；条形图=蓝色>和<geo:22,0；BAR=blue>未定义，因为即使参数名称不区分大小写，未知“BAR”参数的值也不一定如此。
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.
开放地理空间联盟（OGC）的地理标记语言（Geographic Markup Language，GML）是一组表示地理特征的XML模式。由于GML已被广泛接受，本文档包括如何将“geo”URI从GML片段转换为GML片段的说明。本节中的说明不规范。
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.
对于以下部分，“%lat%”、“%lon%”、“%alt%”和“%unc%”分别是纬度、经度、海拔和不确定度值的占位符。映射使用WGS-84，并在以下部分中定义。
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.
注：如果在映射步骤之前定义并应用到“urn:ogc:def:crs:EPSG:：4979”或“urn:ogc:def:crs:EPSG:：4326”的转换，也可以使用其他参考系统中的GML片段。这种转换通常不是无损的。
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.
GML使用XML模式中的“double”类型，映射示例假设GML中“3.32435e2”形式的数字在放入“geo”URI时正确转换为定点。
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.
2D GML“点”[RFC5491]由具有两个坐标的“geo”URI和不存在或为零的不确定性（“u”）参数构成。GML点始终转换为没有不确定性参数的“geo”URI。
'geo' URI:
“geo”URI：
geo:%lat%,%lon%
地理位置：%lat%，%lon%
GML fragment:
GML片段：
<Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
<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.
请注意，不确定性值为零的“geo”URI转换为GML“点”，但GML“点”不能转换为不确定性为零的“geo”URI。
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.
3D GML“点”[RFC5491]由一个“geo”URI构成，该URI具有三个坐标和一个不存在或为零的不确定性参数。GML点始终转换为没有不确定性参数的“geo”URI。
'geo' URI:
“geo”URI：
geo:%lat%,%lon%,%alt%
地理位置：%lat%，%lon%，%alt%
GML fragment:
GML片段：
<Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
<Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non-zero.
GML“圆”[RFC5491]由一个“geo”URI构成，该URI具有两个坐标和一个存在且非零的不确定性参数。
'geo' URI:
“geo”URI：
geo:%lat%,%lon%;u=%unc%
geo:%lat%,%lon%;u=%unc%
GML fragment:
GML片段：
<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>
<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>
A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero.
GML“sphere”[RFC5491]由一个“geo”URI构造而成，该URI具有三个坐标和一个不确定参数，该参数存在且非零。
'geo' URI:
“geo”URI：
geo:%lat%,%lon%,%alt%;u=%unc%
geo:%lat%,%lon%,%alt%;u=%unc%
GML fragment:
GML片段：
<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>
<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>
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.
本文档根据BCP 115（RFC 4395）[RFC4395]中的指南，在URI方案树的IETF部分创建“geo”URI方案。转让所需的定义见第3节。
This document creates a new IANA Registry named "'geo' URI Parameters", according to the information in Section 4 and the definition in this section.
本文档根据第4节中的信息和本节中的定义，创建了一个名为“geo”URI参数的新IANA注册表。
When registering a new 'geo' URI Parameter, the following information MUST be provided:
注册新的“geo”URI参数时，必须提供以下信息：
o Name of the Parameter.
o 参数的名称。
o Whether the Parameter accepts no value ("No value"), values from a predefined set ("Predefined"), or values constrained by a syntax only ("Constrained").
o 参数是否不接受值（“无值”）、来自预定义集的值（“预定义”）或仅受语法约束的值（“受约束”）。
o Reference to the RFC or other permanent and readily available public specification defining the parameters and the new values.
o 参考RFC或其他永久性且随时可用的公共规范，定义参数和新值。
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:
除非存在参数的特定说明（如子注册表的定义），否则在为现有“预定义”的“geo”URI参数注册新值时，必须提供以下信息：
o Name of the Parameter.
o 参数的名称。
o Reference to the RFC or other permanent and readily available public specification defining the new values.
o 参考RFC或定义新值的其他永久性和现成的公共规范。
The following table provides the initial values for this registry:
下表提供了此注册表的初始值：
Parameter Name Value Restriction Reference(s)
----------------------------------------------------------
crs Predefined [RFC5870]
u Constrained [RFC5870]
Parameter Name Value Restriction Reference(s)
----------------------------------------------------------
crs Predefined [RFC5870]
u Constrained [RFC5870]
The Registration Policy for 'geo' URI Parameters and their value definitions is "Specification Required" (which implies "Designated Expert"), as defined in [RFC5226].
“geo”URI参数及其值定义的注册策略为[RFC5226]中定义的“需要规范”（意味着“指定专家”）。
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.2节规定的注册表以及本节和第4节中的信息创建了一个新的IANA子注册表，名为“'geo'URI'crs'参数值”。“crs”参数的语法受第3.3节中给出的ABNF约束。
When registering a new value for the 'crs' parameter, the following information MUST be provided:
为“crs”参数注册新值时，必须提供以下信息：
o Value of the parameter.
o 参数的值。
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 参考RFC或其他永久性且随时可用的公共规范，定义“geo”URI范围内CRS的使用。规范应包含与本文件中给出的WGS-84-特定文本类似的信息。
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.
o 参考CRS的定义文件。如果将URN分配给CRS，则首选使用该URN作为参考。请注意，二维和三维情况下可能存在不同的URN。
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]
crs Value CRS definition(s) Reference(s)
-----------------------------------------------------------
wgs84 urn:ogc:def:crs:EPSG::4326 [RFC5870]
urn:ogc:def:crs:EPSG::4979 [RFC5870]
The registration policy for the "'geo' URI 'crs' Parameter Values" Registry shall require both "Specification Required" and "IESG Approval", as defined in [RFC5226].
“'geo'URI'crs'参数值”注册表的注册政策应要求[RFC5226]中定义的“所需规范”和“IESG批准”。
Section 1 contains some text about the motivation for when to introduce new 'crs' values.
第1节包含一些关于何时引入新“crs”值的动机的文本。
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:
由于“geo”URI不与任何特定协议绑定，并标识物理位置而不是网络资源，因此URI的大多数一般安全注意事项（RFC 3986第7节）不适用。但是，以下（附加）问题适用：
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.
URI语法（第3.3节）允许构造不标识有效位置的“geo”URI。应用程序不得使用具有此类值的URI，并应在遇到此类URI时警告用户。
An example of such a URI referring to an invalid location would be <geo:94,0> (latitude "beyond" north pole).
这样一个URI引用无效位置的示例是<geo:94,0>（北极以外的纬度）。
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.
“geo”URI本身只是对物理位置的不透明引用，由一组空间坐标表示。这不符合GEOPRIV要求[RFC3693]第5.2节中的“位置信息”定义，因为不一定涉及“设备”。
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).
由于也无法在“地理”URI的范围内指定“目标”的标识，因此它也不符合“位置对象”的规范（RFC 3693第5.2节）。
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.
但是，如果在标识目标位置的上下文中使用“geo”URI，则它将成为位置对象的一部分，因此受GEOPRIV规则的约束。
Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met.
因此，当将“geo”URI置于此类上下文中时，必须满足RFC 3693的隐私要求。
Martin Thomson has provided significant text around the definition of the "uncertainty" parameter and the GML mappings.
Martin Thomson围绕“不确定性”参数和GML映射的定义提供了重要的文本。
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.
阿尔弗雷德·霍恩斯对该文件进行了极其有益的深入审查。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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.
[RFC5491]Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年3月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[WGS84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Third Edition", NIMA TR8350.2, January 2000.
[WGS84]国家图像和测绘局，“1984年国防部世界大地测量系统，第三版”，NIMA TR8350.22000年1月。
[ISO.6709.2008] International Organization for Standardization, "Standard representation of geographic point location by coordinates", ISO Standard 6709, 2008.
[ISO.6709.2008]国际标准化组织，“用坐标表示地理点位置的标准”，ISO标准6709，2008。
Authors' Addresses
作者地址
Alexander Mayrhofer IPCom GmbH Karlsplatz 1/2/9 Wien A-1010 Austria
Alexander Mayrhofer IPCom GmbH Karlsplatz 1/2/9维也纳A-1010奥地利
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@ipcom.at
URI: http://www.ipcom.at/
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@ipcom.at
URI: http://www.ipcom.at/
Christian Spanring 73 Josephine Ave Somerville 02144
克里斯蒂安斯潘灵73约瑟芬大道萨默维尔02144号
Email: christian@spanring.eu
URI: http://www.spanring.eu/
Email: christian@spanring.eu
URI: http://www.spanring.eu/