Internet Engineering Task Force (IETF) J. Polk
Request for Comments: 6225 M. Linsner
Obsoletes: 3825 Cisco Systems
Category: Standards Track M. Thomson
ISSN: 2070-1721 Andrew Corporation
B. Aboba, Ed.
Microsoft Corporation
July 2011
Internet Engineering Task Force (IETF) J. Polk
Request for Comments: 6225 M. Linsner
Obsoletes: 3825 Cisco Systems
Category: Standards Track M. Thomson
ISSN: 2070-1721 Andrew Corporation
B. Aboba, Ed.
Microsoft Corporation
July 2011
Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information
用于基于坐标的位置配置信息的动态主机配置协议选项
Abstract
摘要
This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825.
本文档为客户机基于坐标的地理位置指定了动态主机配置协议选项（DHCPv4和DHCPv6）。位置配置信息（LCI）包括纬度、经度和高度，每个位置都有分辨率或不确定性指示器。单独的参数表示每个值的参考基准。本文件废除了RFC 3825。
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/rfc6225.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6225.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Resolution and Uncertainty .................................4
2. DHCP Option Formats .............................................6
2.1. DHCPv6 GeoLoc Option .......................................6
2.2. DHCPv4 Options .............................................8
2.3. Latitude and Longitude Fields .............................11
2.4. Altitude ..................................................14
2.5. Datum .....................................................16
3. Security Considerations ........................................17
4. IANA Considerations ............................................17
4.1. DHCP Options ..............................................17
4.2. Altitude Type Registry ....................................18
4.3. Datum Registry ............................................18
4.4. GeoLoc Option Version Registry ............................19
5. Acknowledgments ................................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................21
Appendix A. GML Mapping ...........................................23
A.1. GML Templates ............................................23
Appendix B. Calculations of Resolution ............................27
B.1. Location Configuration Information of "White House"
(Example 1) ..............................................27
B.2. Location Configuration Information of "Sears Tower"
(Example 2) ..............................................29
Appendix C. Calculations of Uncertainty ...........................30
C.1. Location Configuration Information of "Sydney Opera
House" (Example 3) .......................................30
Appendix D. Changes from RFC 3825 .................................34
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Resolution and Uncertainty .................................4
2. DHCP Option Formats .............................................6
2.1. DHCPv6 GeoLoc Option .......................................6
2.2. DHCPv4 Options .............................................8
2.3. Latitude and Longitude Fields .............................11
2.4. Altitude ..................................................14
2.5. Datum .....................................................16
3. Security Considerations ........................................17
4. IANA Considerations ............................................17
4.1. DHCP Options ..............................................17
4.2. Altitude Type Registry ....................................18
4.3. Datum Registry ............................................18
4.4. GeoLoc Option Version Registry ............................19
5. Acknowledgments ................................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................21
Appendix A. GML Mapping ...........................................23
A.1. GML Templates ............................................23
Appendix B. Calculations of Resolution ............................27
B.1. Location Configuration Information of "White House"
(Example 1) ..............................................27
B.2. Location Configuration Information of "Sears Tower"
(Example 2) ..............................................29
Appendix C. Calculations of Uncertainty ...........................30
C.1. Location Configuration Information of "Sydney Opera
House" (Example 3) .......................................30
Appendix D. Changes from RFC 3825 .................................34
The physical location of a network device has a range of applications. In particular, emergency telephony applications rely on knowing the location of a caller in order to determine the correct emergency center.
网络设备的物理位置有一系列应用。特别是，紧急电话应用程序依赖于知道呼叫者的位置以确定正确的紧急中心。
The location of a device can be represented either in terms of geospatial (or geodetic) coordinates, or as a civic address. Different applications may be more suited to one form of location information; therefore, both the geodetic and civic forms may be used simultaneously.
设备的位置可以用地理空间（或大地坐标）坐标表示，也可以用城市地址表示。不同的应用可能更适合于一种形式的位置信息；因此，可以同时使用大地测量和城市形式。
This document specifies Dynamic Host Configuration Protocol v4 (DHCPv4) [RFC2131] and DHCPv6 [RFC3315] options for the coordinate-based geographic location of the client, to be provided by the server. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information" [RFC4776] specifies DHCP options for civic addresses.
本文档指定了动态主机配置协议v4（DHCPv4）[RFC2131]和DHCPv6[RFC3315]选项，用于服务器提供的基于坐标的客户端地理位置。“用于思域地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”[RFC4776]指定思域地址的DHCP选项。
The geodetic coordinate options defined in this document and the civic address options defined in RFC 4776 [RFC4776] enable a DHCP client to obtain its location. For example, a wired Ethernet host might use these options for location determination. In this case, the location information could be derived from a wiremap by the DHCP server, using the Circuit ID Relay Agent Information Option (RAIO) defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server could correlate the Circuit ID with the geographic location where the identified circuit terminates (such as the location of the wall jack).
本文件中定义的大地坐标选项和RFC 4776[RFC4776]中定义的公民地址选项使DHCP客户端能够获取其位置。例如，有线以太网主机可能使用这些选项来确定位置。在这种情况下，DHCP服务器可以使用RFC 3046[RFC3046]中定义的电路ID中继代理信息选项（RAIO）（作为子选项1）从线图中导出位置信息。DHCP服务器可以将电路ID与标识的电路终止的地理位置（例如墙壁插孔的位置）关联起来。
The mechanism defined here may also be utilized to provide location to wireless hosts. DHCP relay agent sub-options (RAIO) [RFC3046] provide one method a DHCP server might use to perform host location determination. Currently, the relay agent sub-options do not include data sets required for device-level location determination of wireless hosts. In cases where the DHCP server uses RAIO for location determination, a wireless host can use this mechanism to discover the location of the radio access point, or the area of coverage for the radio access point.
这里定义的机制也可用于向无线主机提供位置。DHCP中继代理子选项（RAIO）[RFC3046]提供了DHCP服务器可能用于执行主机位置确定的一种方法。目前，中继代理子选项不包括无线主机的设备级位置确定所需的数据集。在DHCP服务器使用RAIO进行位置确定的情况下，无线主机可以使用此机制来发现无线接入点的位置或无线接入点的覆盖区域。
An important feature of this specification is that after the relevant DHCP exchanges have taken place, the location information is stored on the end device rather than somewhere else, where retrieving it might be difficult in practice.
本规范的一个重要特征是，在相关的DHCP交换发生之后，位置信息存储在终端设备上，而不是存储在其他地方，在实践中检索位置信息可能会很困难。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The DHCP options defined in this document include fields quantifying the resolution or uncertainty associated with a target location. No inferences relating to privacy policies can be drawn from either uncertainty or resolution values.
本文档中定义的DHCP选项包括量化与目标位置相关的分辨率或不确定性的字段。不能从不确定性或分辨率值中得出与隐私政策相关的推论。
As utilized in this document, resolution refers to the accuracy of a reported location, as expressed by the number of valid bits in each of the Latitude, Longitude, and Altitude fields.
本文件中使用的分辨率是指报告位置的精度，由每个纬度、经度和高度字段中的有效位数表示。
The Latitude (LaRes), Longitude (LoRes), and Altitude (AltRes) Resolution fields are encoded as 6-bit, unsigned integer values. In the DHCPv4 GeoConf Option 123, the LaRes, LoRes, and AltRes fields are used to encode the number of bits of resolution. The resolution sub-fields accommodate the desire to easily adjust the precision of a reported location. Contents beyond the claimed resolution MAY be randomized to obscure greater precision that might be available.
纬度（LaRes）、经度（LoRes）和高度（AltRes）分辨率字段编码为6位无符号整数值。在DHCPv4 GeoConf选项123中，LaRes、LoRes和AltRes字段用于编码分辨率位数。分辨率子字段满足轻松调整报告位置精度的要求。超出要求的分辨率的内容可能会随机化，以模糊可能可用的更高精度。
In the context of location technology, uncertainty is a quantification of errors. Any method for determining location is subject to some sources of error; uncertainty describes the amount of error that is present. Uncertainty might be the coverage area of a wireless transmitter, the extent of a building, or a single room.
在定位技术中，不确定性是误差的量化。任何确定位置的方法都会受到某些误差源的影响；不确定性描述存在的误差量。不确定性可能是无线发射机的覆盖面积、建筑物的范围或单个房间。
Uncertainty is usually represented as an area within which the target is located. In this document, each of the three axes can be assigned an uncertainty value. In effect, this describes a rectangular prism, which may be used as a coarse representation of a more complex shape that fits within it. See Section 2.3.2 for more detail on the correspondence between shapes and uncertainty.
不确定性通常表示为目标所在区域。在本文件中，三个轴中的每一个都可以指定一个不确定度值。实际上，这描述了一个矩形棱柱体，它可以用作更复杂形状的粗略表示。有关形状和不确定性之间对应关系的更多详细信息，请参见第2.3.2节。
When representing locations from sources that can quantify uncertainty, the goal is to find the smallest possible rectangular prism that this format can describe. This is achieved by taking the minimum and maximum values on each axis and ensuring that the final encoding covers these points. This increases the region of uncertainty, but ensures that the region that is described encompasses the target location.
当从可以量化不确定性的来源表示位置时，目标是找到这种格式能够描述的最小可能的矩形棱镜。这是通过获取每个轴上的最小值和最大值并确保最终编码覆盖这些点来实现的。这增加了不确定性区域，但确保所描述的区域包含目标位置。
The DHCPv4 option formats defined in this document support resolution and uncertainty parameters. The DHCPv4 GeoConf Option 123 includes a resolution parameter for each of the dimensions of location. Since this resolution parameter need not apply to all dimensions equally, a resolution value is included for each of the three location elements. The DHCPv4 GeoLoc Option 144 as well as the DHCPv6 GeoLoc Option 63 format utilize an uncertainty parameter.
本文件中定义的DHCPv4选项格式支持分辨率和不确定性参数。DHCPv4 GeoConf选项123包括每个位置维度的分辨率参数。由于此分辨率参数不必平等地应用于所有标注，因此三个位置元素中的每一个都包含一个分辨率值。DHCPv4 GeoLoc选项144以及DHCPv6 GeoLoc选项63格式使用不确定性参数。
Appendix A describes the mapping of DHCP option values to the Geography Markup Language (GML). Appendix B of this document provides examples showing the calculation of resolution values. Appendix C provides an example demonstrating calculation of uncertainty values.
附录A描述了DHCP选项值到地理标记语言（GML）的映射。本文件附录B提供了显示分辨率值计算的示例。附录C提供了一个示例，演示了不确定度值的计算。
Since the Presence Information Data Format Location Object (PIDF-LO) [RFC4119] [RFC5491] is used to convey location and the associated uncertainty within an emergency call [Convey], a mechanism is needed to convert the information contained within the DHCPv4 and DHCPv6 options to PIDF-LO. This document describes the following conversions:
由于存在信息数据格式位置对象（PIDF-LO）[RFC4119][RFC5491]用于传达紧急呼叫[Transfer]中的位置和相关不确定性，因此需要一种机制将DHCPv4和DHCPv6选项中包含的信息转换为PIDF-LO。本文档描述了以下转换：
o DHCPv4 GeoConf Option 123 to PIDF-LO
o DHCPv4 GeoConf选项123至PIDF-LO
o DHCPv4 GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 to PIDF-LO
o 至PIDF-LO的DHCPv4 GeoLoc选项144和DHCPv6 GeoLoc选项63
o PIDF-LO to DHCP GeoLoc Option 144 and DHCPv6 GeoLoc Option 63
o PIDF-LO至DHCP GeoLoc选项144和DHCPv6 GeoLoc选项63
Conversion to PIDF-LO does not increase uncertainty; conversion from PIDF-LO to the DHCPv4 GeoLoc Option 144 and the DHCPv6 GeoLoc Option 63 increases uncertainty by less than a factor of 2 in each dimension. Since it is not possible to translate an arbitrary PIDF-LO to the DHCP GeoConf Option 123 with a bounded increase in uncertainty, the conversion is not specified.
转换为PIDF-LO不会增加不确定性；从PIDF-LO转换为DHCPv4 GeoLoc选项144和DHCPv6 GeoLoc选项63，每个维度的不确定性增加不到2倍。由于不可能将任意PIDF-LO转换为DHCP GeoConf选项123，且不确定性有一定的增加，因此未指定转换。
This section defines the format for the DHCPv4 and DHCPv6 options. These options utilize a similar format, differing primarily in the option code.
本节定义DHCPv4和DHCPv6选项的格式。这些选项使用类似的格式，主要不同于选项代码。
The format of the DHCPv6 [RFC3315] GeoLoc Option is as follows:
DHCPv6[RFC3315]GeoLoc选项的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code (63) | OptLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code (63) | OptLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 16 bits. The code for the DHCP Option Code (63).
代码：16位。DHCP选项代码（63）的代码。
OptLen: Option Length. For version 1, the option length is 16.
OptLen：选项长度。对于版本1，选项长度为16。
LatUnc: 6 bits. When the Ver field = 1, this field represents latitude uncertainty. The contents of this field are undefined for other values of the Ver field.
LatUnc:6位。当Ver字段=1时，此字段表示纬度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Latitude: A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3.
纬度：由9位整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
LongUnc: 6 bits. When the Ver field = 1, this field represents longitude uncertainty. The contents of this field are undefined for other values of the Ver field.
LongUnc:6位。当Ver字段=1时，此字段表示经度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Longitude: A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3.
经度：由9位整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
AType: 4 bits. Altitude Type, defined in Section 2.4.
类型：4位。第2.4节中定义的高度类型。
AltUnc: 6 bits. When the Ver field = 1, this field represents altitude uncertainty. The contents of this field are undefined for other values of the Ver field.
AltUnc:6位。当Ver字段=1时，此字段表示高度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：由AType字段定义的30位值，如第2.4节所述。
Ver: The Ver field is 2 bits, providing for four potential versions. This specification defines the behavior of version 1. The Ver field is always located at the same offset from the beginning of the option, regardless of the version in use. DHCPv6 clients implementing this specification MUST support receiving version 1 responses. DHCPv6 servers implementing this specification MUST send version 1 responses.
版本：版本字段为2位，提供四种可能的版本。本规范定义了版本1的行为。“版本”字段始终位于与选项开头相同的偏移处，而与使用的版本无关。实现此规范的DHCPv6客户端必须支持接收版本1响应。实现此规范的DHCPv6服务器必须发送版本1响应。
Res: 3 bits. The Res field is reserved. These bits have been used by [IEEE-802.11y], but are not defined within this specification.
Res:3位。Res字段是保留的。这些位已被[IEEE-802.11y]使用，但未在本规范中定义。
Datum: 3 bits. The Map Datum used for the coordinates given in this option.
基准：3位。用于此选项中给定坐标的地图基准。
The format of the DHCPv4 GeoConf Option is as follows:
DHCPv4 GeoConf选项的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 123 | Length | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) | Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 123 | Length | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) | Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 8 bits. The code for the DHCPv4 GeoConf Option (123).
代码：8位。DHCPv4 GeoConf选项的代码（123）。
Length: 8 bits. The length of the option, in octets. The option length is 16.
长度：8位。选项的长度，以八位字节为单位。选项长度为16。
LaRes: 6 bits. This field represents latitude resolution.
LaRes:6位。此字段表示纬度分辨率。
Latitude: A 34-bit fixed-point value consisting of 9 bits of signed integer and 25 bits of fraction, interpreted as described in Section 2.3.
纬度：由9位有符号整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
LoRes: 6 bits. This field represents longitude resolution.
知识：6位。此字段表示经度分辨率。
Longitude: A 34-bit fixed-point value consisting of 9 bits of signed integer and 25 bits of fraction, interpreted as described in Section 2.3.
经度：由9位有符号整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
AType: 4 bits. Altitude Type, defined in Section 2.4.
类型：4位。第2.4节中定义的高度类型。
AltRes: 6 bits. This field represents altitude resolution.
AltRes:6位。此字段表示高度分辨率。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：由AType字段定义的30位值，如第2.4节所述。
Res: 5 bits. The Res field is reserved. These bits have been used by IEEE 802.11y [IEEE-802.11y], but are not defined within this specification.
Res:5位。Res字段是保留的。这些位已被IEEE 802.11y[IEEE-802.11y]使用，但未在本规范中定义。
Datum: 3 bits. The Map Datum used for the coordinates given in this option.
基准：3位。用于此选项中给定坐标的地图基准。
The format of the DHCPv4 GeoLoc Option is as follows:
DHCPv4 GeoLoc选项的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 144 | Length | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LongUnc | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 144 | Length | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LongUnc | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 8 bits. The code for the DHCPv4 GeoLoc Option (144).
代码：8位。DHCPv4 GeoLoc选项的代码（144）。
Length: 8 bits. The length of the option, in octets. For version 1, the option length is 16.
长度：8位。选项的长度，以八位字节为单位。对于版本1，选项长度为16。
LatUnc: 6 bits. When the Ver field = 1, this field represents latitude uncertainty. The contents of this field are undefined for other values of the Ver field.
LatUnc:6位。当Ver字段=1时，此字段表示纬度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Latitude: A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3.
纬度：由9位整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
LongUnc: 6 bits. When the Ver field = 1, this field represents longitude uncertainty. The contents of this field are undefined for other values of the Ver field.
LongUnc:6位。当Ver字段=1时，此字段表示经度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Longitude: A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3.
经度：由9位整数和25位小数组成的34位定点值，如第2.3节所述进行解释。
AType: 4 bits. Altitude Type, defined in Section 2.4.
类型：4位。第2.4节中定义的高度类型。
AltUnc: 6 bits. When the Ver field = 1, this field represents altitude uncertainty. The contents of this field are undefined for other values of the Ver field.
AltUnc:6位。当Ver字段=1时，此字段表示高度不确定性。对于Ver字段的其他值，此字段的内容未定义。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：由AType字段定义的30位值，如第2.4节所述。
Ver: The Ver field is 2 bits, providing for four potential versions. This specification defines the behavior of version 1. The Ver field is always located at the same offset from the beginning of the option, regardless of the version in use.
版本：版本字段为2位，提供四种可能的版本。本规范定义了版本1的行为。“版本”字段始终位于与选项开头相同的偏移处，而与使用的版本无关。
Res: 3 bits. The Res field is reserved. These bits have been used by [IEEE-802.11y], but are not defined within this specification.
Res:3位。Res字段是保留的。这些位已被[IEEE-802.11y]使用，但未在本规范中定义。
Datum: 3 bits. The Map Datum used for the coordinates given in this option.
基准：3位。用于此选项中给定坐标的地图基准。
DHCPv4 clients implementing this specification MUST support receiving the DHCPv4 GeoLoc Option 144 (version 1), and MAY support receiving the DHCPv4 GeoConf Option 123 (originally defined in RFC 3825 [RFC3825]).
实现本规范的DHCPv4客户端必须支持接收DHCPv4 GeoLoc选项144（版本1），并且可能支持接收DHCPv4 GeoConf选项123（最初在RFC 3825[RFC3825]中定义）。
DHCPv4 clients request the DHCPv4 server to send GeoConf Option 123, GeoLoc Option 144, or both via inclusion of the Parameter Request List option. As noted in Section 9.8 of RFC 2132 [RFC2132]:
DHCPv4客户端通过包含参数请求列表选项，请求DHCPv4服务器发送GeoConf选项123、GeoLoc选项144或两者。如RFC 2132[RFC2132]第9.8节所述：
This option is used by a DHCP client to request values for specified configuration parameters. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document.
DHCP客户端使用此选项请求指定配置参数的值。请求的参数列表指定为n个八位字节，其中每个八位字节都是本文档中定义的有效DHCP选项代码。
The client MAY list the options in order of preference. The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client.
客户可以按优先顺序列出选项。DHCP服务器不需要按请求的顺序返回选项，但必须尝试按客户端请求的顺序插入请求的选项。
When DHCPv4 and DHCPv6 clients implementing this specification do not understand a datum value, they MUST assume a World Geodetic System 1984 (WGS84) [WGS84] datum (European Petroleum Survey Group (EPSG) [EPSG] 4326 or 4979, depending on whether there is an altitude value present) and proceed accordingly. Assuming that a less accurate location value is better than none, this ensures that some (perhaps less accurate) location is available to the client.
当实施本规范的DHCPv4和DHCPv6客户不了解基准值时，他们必须采用1984年世界大地测量系统（WGS84）[WGS84]基准（欧洲石油测量集团（EPSG）[EPSG]4326或4979，取决于是否存在海拔值），并相应地进行操作。假设不太准确的位置值比没有好，这将确保客户端可以使用某些（可能不太准确的）位置。
A DHCPv4 server implementing this specification MUST support sending GeoLoc Option 144 version 1 and SHOULD support sending GeoConf Option 123 in responses.
实现此规范的DHCPv4服务器必须支持发送GeoLoc选项144版本1，并且应支持在响应中发送Geocconf选项123。
A DHCPv4 server that provides location information SHOULD honor the Parameter Request List included by the DHCPv4 client in order to decide whether to send GeoConf Option 123, GeoLoc Option 144, or both in the Response.
提供位置信息的DHCPv4服务器应遵守DHCPv4客户端包含的参数请求列表，以便决定是在响应中发送GeoConf选项123、GeoLoc选项144，还是同时发送这两个选项。
The latitude and longitude values in this specification are encoded as 34-bit, two's complement, fixed-point values with 9 integer bits and 25 fractional bits. The exact meaning of these values is determined by the datum; the description in this section applies to the datums defined in this document. This document uses the same definition for all datums it specifies.
本规范中的纬度和经度值编码为34位、2的补码、9个整数位和25个小数位的定点值。这些值的确切含义由基准确定；本节中的说明适用于本文件中定义的基准。本文档对其指定的所有基准使用相同的定义。
When encoding, latitude and longitude values are rounded to the nearest 34-bit binary representation. This imprecision is considered acceptable for the purposes to which this form is intended to be applied and is ignored when decoding.
编码时，纬度和经度值四舍五入到最接近的34位二进制表示形式。这种不精确性被认为是可接受的，在解码时被忽略。
Positive latitudes are north of the equator, and negative latitudes are south of the equator. Positive longitudes are east of the Prime Meridian, and negative (two's complement) longitudes are west of the Prime Meridian.
正纬度在赤道以北，负纬度在赤道以南。正经度位于本初子午线以东，负经度（二者互补）位于本初子午线以西。
Within the coordinate reference systems defined in this document (Datum values 1-3), longitude values outside the range of -180 to 180 decimal degrees or latitude values outside the range of -90 to 90 degrees MUST be considered invalid. Server implementations SHOULD prevent the entry of invalid values within the selected coordinate reference system. Location consumers MUST ignore invalid location coordinates and SHOULD log errors related to invalid location.
在本文件定义的坐标参考系内（基准值1-3），超出-180到180十进制度数范围的经度值或超出-90到90度范围的纬度值必须视为无效。服务器实现应防止在所选坐标系中输入无效值。位置使用者必须忽略无效的位置坐标，并应记录与无效位置相关的错误。
In the DHCPv4 GeoConf Option 123, the LaRes value encodes the number of high-order latitude bits that MUST be considered valid. Any bits entered to the right of this limit MUST NOT be considered valid and might be purposely false, or zeroed by the sender. The examples in Appendix B illustrate that a smaller value in the resolution field increases the area within which the device is located. A value of 2 in the LaRes field indicates a precision of no greater than 1/6th that of the globe (see the first example of Appendix B). A value of 34 in the LaRes field indicates a precision of about 3.11 mm in latitude at the equator.
在DHCPv4 GeoConf选项123中，LaRes值编码必须视为有效的高阶纬度位数。输入到该限制右侧的任何位都不得被视为有效位，可能是发送方故意为假或归零。附录B中的示例说明，分辨率字段中的较小值会增加设备所在的区域。LaRes字段中的值为2表示精度不超过地球仪的1/6（见附录B的第一个示例）。LaRes字段中的值为34表示赤道纬度的精度约为3.11 mm。
In the DHCPv4 GeoConf Option 123, the LoRes value encodes the number of high-order longitude bits that MUST be considered valid. Any bits entered to the right of this limit MUST NOT be considered valid and might be purposely false, or zeroed by the sender. A value of 2 in the LoRes field indicates precision of no greater than 1/6th that of the globe (see the first example of Appendix B). A value of 34 in the LoRes field indicates a precision of about 2.42 mm in longitude (at the equator). Because lines of longitude converge at the poles, the distance is smaller (better precision) for locations away from the equator.
在DHCPv4 GeoConf选项123中，LoRes值编码必须视为有效的高阶经度位的数量。输入到该限制右侧的任何位都不得被视为有效位，可能是发送方故意为假或归零。LoRes字段中的值为2表示精度不超过地球仪精度的1/6（参见附录B的第一个示例）。LoRes字段中的值为34表示经度精度约为2.42 mm（在赤道处）。因为经线在两极会聚，所以远离赤道的位置距离更小（精度更好）。
In the DHCPv6 GeoLoc Option 63 and the DHCPv4 GeoLoc Option 144, the Latitude and Longitude Uncertainty fields (LatUnc and LongUnc) quantify the amount of uncertainty in each of the latitude and longitude values, respectively. A value of 0 is reserved to indicate that the uncertainty is unknown; values greater than 34 are reserved.
在DHCPv6 GeoLoc选项63和DHCPv4 GeoLoc选项144中，纬度和经度不确定性字段（LatUnc和LongUnc）分别量化每个纬度和经度值中的不确定性量。保留值0表示不确定度未知；保留大于34的值。
A point within the region of uncertainty is selected to be the encoded point; the centroid of the region is often an appropriate choice. The value for uncertainty is taken as the distance from the selected point to the furthest extreme of the region of uncertainty on that axis. This is demonstrated in the figure below, which shows a two-dimensional polygon that is projected on each axis. In the figure, "X" marks the point that is selected; the ranges marked with "U" indicate the uncertainty.
选择不确定区域内的点作为编码点；区域的质心通常是一个合适的选择。不确定度值被视为从选定点到该轴上不确定度区域最远端的距离。下图展示了这一点，图中显示了投影在每个轴上的二维多边形。在图中，“X”标记所选的点；标有“U”的范围表示不确定度。
___ ___________
^ | / |
| | / |
| | / |
U | / |
| | ( |
V | | |
--X | X |
| | `---------.
| | |
| | |
| | |
- `-------------------------'
___ ___________
^ | / |
| | / |
| | / |
U | / |
| | ( |
V | | |
--X | X |
| | `---------.
| | |
| | |
| | |
- `-------------------------'
|---------X---------------|
|<------U------>|
|---------X---------------|
|<------U------>|
Key
---
Key
---
V, ^ = vertical arrows, delimiting the vertical uncertainty range. <> = horizontal arrows, delimiting the horizontal uncertainty range.
五、 ^=垂直箭头，划定垂直不确定性范围。<>=水平箭头，划定水平不确定度范围。
Uncertainty applies to each axis independently.
不确定性独立地应用于每个轴。
The amount of uncertainty can be determined from the encoding by taking 2 to the power of 8, less the encoded value, as is shown in the following formula, where "x" is the encoded integer value:
The amount of uncertainty can be determined from the encoding by taking 2 to the power of 8, less the encoded value, as is shown in the following formula, where "x" is the encoded integer value:translate error, please retry
uncertainty = 2 ^ ( 8 - x )
uncertainty = 2 ^ ( 8 - x )
The result of this formula is expressed in degrees of latitude or longitude. The uncertainty is added to the base latitude or longitude value to determine the maximum value in the uncertainty range; similarly, the uncertainty is subtracted from the base value to determine the minimum value. Note that because lines of longitude converge at the poles, the actual distance represented by this uncertainty changes with the distance from the equator.
此公式的结果以纬度或经度表示。将不确定度添加到基准纬度或经度值，以确定不确定度范围内的最大值；同样，从基准值中减去不确定度，以确定最小值。请注意，由于经线在两极会聚，因此此不确定度表示的实际距离随与赤道的距离而变化。
If the maximum or minimum latitude values derived from applying uncertainty are outside the range of -90 to +90, these values are trimmed to within this range. If the maximum or minimum longitude values derived from applying uncertainty are outside the range of -180 to +180, then these values are normalized to this range by adding or subtracting 360 as necessary.
如果应用不确定性得出的最大或最小纬度值超出-90到+90的范围，则这些值将被修剪到该范围内。如果应用不确定性得出的最大或最小经度值超出-180到+180的范围，则根据需要通过加或减360将这些值标准化到该范围。
The encoded value is determined by subtracting the next highest whole integer value for the base 2 logarithm of uncertainty from 8, as is shown by the following formula, where uncertainty is the midpoint of the known range less the lower bound of that range:
通过从8中减去不确定度的基数2对数的次高整数值来确定编码值，如以下公式所示，其中不确定度是已知范围的中点减去该范围的下限：
x = 8 - ceil( log2( uncertainty ) )
x = 8 - ceil( log2( uncertainty ) )
Note that the result of encoding this value increases the range of uncertainty to the next available power of two; subsequent repeated encodings and decodings do not change the value. Only increasing uncertainty means that the associated confidence does not have to decrease.
请注意，对该值进行编码的结果将不确定性范围增加到下一个可用的二次方；后续重复的编码和解码不会更改该值。只有不断增加的不确定性意味着相关的置信度不必降低。
How the altitude value is interpreted depends on the Altitude Type (AType) value and the selected datum. Three Altitude Type values are defined in this document: unknown (0), meters (1), and floors (2).
海拔值的解释方式取决于海拔类型（AType）值和所选基准。本文档中定义了三个高度类型值：未知（0）、米（1）和楼层（2）。
In some cases, the altitude of the location might not be provided. An Altitude Type value of zero indicates that the altitude is not given to the client. In this case, the Altitude and Altitude Uncertainty fields can contain any value and MUST be ignored.
在某些情况下，可能无法提供位置的海拔高度。高度类型值为零表示高度未提供给客户端。在这种情况下，高度和高度不确定性字段可以包含任何值，必须忽略。
If the Altitude Type has a value of one, altitude is measured in meters, in relation to the zero set by the vertical datum. For AType = 1, the altitude value is expressed as a 30-bit, fixed-point, two's complement integer with 22 integer bits and 8 fractional bits.
如果高度类型的值为1，则相对于垂直基准设置的零点，以米为单位测量高度。对于AType=1，高度值表示为30位定点2的补码整数，包含22个整数位和8个小数位。
A value of two for Altitude Type indicates that the altitude value is measured in floors. Since altitude in meters may not be known within a building, a floor indication may be more useful. For AType = 2, the altitude value is expressed as a 30-bit, fixed-point, two's complement integer with 22 integer bits and 8 fractional bits.
高度类型的值为2表示高度值是以楼层为单位测量的。由于建筑物内可能不知道以米为单位的高度，楼层指示可能更有用。对于AType=2，高度值表示为30位定点2的补码整数，包含22个整数位和8个小数位。
This value is relevant only in relation to a building; the value is relative to the ground level of the building. Floors located below ground level are represented by negative values. In some buildings, it might not be clear which floor is at ground level, or an intermediate floor might be hard to identify as such. Determining
该值仅与建筑物相关；该值相对于建筑的地面标高。位于地面以下的楼层用负值表示。在一些建筑物中，可能不清楚哪一层位于地面，或者很难识别中间层。决定
what floor is at ground level and what constitutes a sub-floor as opposed to a naturally numbered floor is left to local interpretation.
与自然编号的楼层相反，什么楼层位于地面，什么构成子楼层，留待当地解释。
Larger values represent floors that are farther away from floor 0 such that:
较大的值表示离楼板0较远的楼板，以便：
- if positive, the floor value is farther above the ground floor.
- 如果为正值，则楼层值比一楼高出更远。
- if negative, the floor value is farther below the ground floor.
- 如果为负值，则楼层值比一楼低得多。
Non-integer values can be used to represent intermediate or sub-floors, such as mezzanine levels. Example: a mezzanine between floor 1 and floor 2 could be represented as a value of 1.25. Example: mezzanines between floor 4 and floor 5 could be represented as values of 4.5 and 4.75.
非整数值可用于表示中间楼层或子楼层，例如夹层楼层。示例：楼层1和楼层2之间的夹层可以表示为值1.25。示例：楼层4和楼层5之间的夹层可以表示为值4.5和4.75。
In the DHCPv4 GeoConf Option 123, the altitude resolution (AltRes) value encodes the number of high-order altitude bits that should be considered valid. Values above 30 (decimal) are undefined and reserved.
在DHCPv4 GeoConf选项123中，高度分辨率（AltRes）值对应被视为有效的高阶高度位数进行编码。大于30（十进制）的值是未定义和保留的。
If the Altitude Type value is one (AType = 1), an AltRes value of 0.0 would indicate an unknown altitude. The most precise altitude would have an AltRes value of 30. Many values of AltRes would obscure any variation due to vertical datum differences.
如果高度类型值为1（AType=1），AltRes值为0.0表示未知高度。最精确的高度将具有30的AltRes值。许多AltRes值会掩盖由于垂直基准差异引起的任何变化。
The AltRes field SHOULD be set to maximum precision when AType = 2 (floors) when a floor value is included in the DHCP Reply, or when AType = 0, to denote that the floor isn't known. An altitude coded as AType = 2, AltRes = 30, and Altitude = 0.0 is meaningful even outside a building, and represents ground level at the given latitude and longitude.
当DHCP应答中包含楼层值时，AType=2（楼层）或AType=0时，AltRes字段应设置为最大精度，以表示楼层未知。编码为AType=2、AltRes=30和ALITION=0.0的高度即使在建筑物外也有意义，表示给定纬度和经度的地面标高。
In the DHCPv6 GeoLoc Option 63 or the DHCPv4 GeoLoc Option 144, the AltUnc value quantifies the amount of uncertainty in the altitude value. As with LatUnc and LongUnc, a value of 0 for AltUnc is reserved to indicate that altitude uncertainty is not known; values above 30 are also reserved. Altitude uncertainty only applies to Altitude Type 1.
在DHCPv6 GeoLoc选项63或DHCPv4 GeoLoc选项144中，AltUnc值量化了高度值中的不确定性量。与LatUnc和LongUnc一样，AltUnc的值保留为0，表示高度不确定性未知；大于30的值也保留。高度不确定性仅适用于高度类型1。
The amount of altitude uncertainty can be determined by the following formula, where x is the encoded integer value:
高度不确定性的大小可通过以下公式确定，其中x是编码整数值：
Uncertainty = 2 ^ ( 21 - x )
Uncertainty = 2 ^ ( 21 - x )
This value uses the same units as the associated altitude.
该值使用与相关高度相同的单位。
Similarly, a value for the encoded integer value can be derived by the following formula:
类似地，编码整数值的值可以通过以下公式导出：
x = 21 - ceil( log2( uncertainty ) )
x = 21 - ceil( log2( uncertainty ) )
The Datum field determines how coordinates are organized and related to the real world. Three datums are defined in this document, based on the definitions in [OGP.Geodesy]:
基准字段确定坐标的组织方式以及与真实世界的关系。根据[OGP.大地测量学]中的定义，本文件定义了三个基准：
1: WGS84 (Latitude, Longitude, Altitude): The World Geodetic System 1984 [WGS84] coordinate reference system.
1:WGS84（纬度、经度、高度）：1984年世界大地测量系统[WGS84]坐标参考系。
This datum is identified by the European Petroleum Survey Group (EPSG)/International Association of Oil & Gas Producers (OGP) with the code 4979, or by the URN "urn:ogc:def:crs:EPSG::4979". Without altitude, this datum is identified by the EPSG/OGP code 4326 and the URN "urn:ogc:def:crs:EPSG::4326".
该数据由欧洲石油调查集团（EPSG）/国际石油天然气生产商协会（OGP）确定，代码为4979，或由URN“URN:ogc:def:crs:EPSG:：4979”确定。如果没有高度，该基准由EPSG/OGP代码4326和URN“URN:ogc:def:crs:EPSG:：4326”标识。
2: NAD83 (Latitude, Longitude) + NAVD88: This datum uses a combination of the North American Datum 1983 (NAD83) for horizontal (Latitude and Longitude) values, plus the North American Vertical Datum of 1988 (NAVD88) vertical datum.
2:NAD83（纬度、经度）+NAVD88：该基准使用北美基准1983（NAD83）的水平（纬度和经度）值和北美垂直基准1988（NAVD88）的垂直基准的组合。
This datum is used for referencing location on land (not near tidal water) within North America.
该基准用于参考北美陆地上的位置（不靠近潮水）。
NAD83 is identified by the EPSG/OGP code of 4269, or the URN "urn:ogc:def:crs:EPSG::4269". NAVD88 is identified by the EPSG/ OGP code of 5703, or the URN "urn:ogc:def:crs:EPSG::5703".
NAD83由EPSG/OGP代码4269或URN“URN:ogc:def:crs:EPSG:：4269”标识。NAVD88由EPSG/OGP代码5703或URN“URN:ogc:def:crs:EPSG:：5703”标识。
3: NAD83 (Latitude, Longitude) + MLLW: This datum uses a combination of the North American Datum 1983 (NAD83) for horizontal (Latitude and Longitude) values, plus the Mean Lower Low Water (MLLW) vertical datum.
3:NAD83（纬度、经度）+MLLW：该基准使用北美基准1983（NAD83）的水平（纬度和经度）值和平均低水位（MLLW）垂直基准的组合。
This datum is used for referencing location on or near tidal water within North America.
该基准用于参考北美潮汐水上或附近的位置。
NAD83 is identified by the EPSG/OGP code of 4269, or the URN "urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code or URN.
NAD83由EPSG/OGP代码4269或URN“URN:ogc:def:crs:EPSG:：4269”标识。MLLW没有特定的代码或URN。
All hosts MUST support the WGS84 datum (Datum 1).
所有主机必须支持WGS84基准（基准1）。
Geopriv requirements (including security requirements) are discussed in "Geopriv Requirements" [RFC3693]. A threat analysis is provided in "Threat Analysis of the Geopriv Protocol" [RFC3694].
Geopriv要求（包括安全要求）在“Geopriv要求”[RFC3693]中讨论。“Geopriv协议的威胁分析”[RFC3694]中提供了威胁分析。
Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover this LCI.
由于DHCP消息没有隐私保护，可以监视DHCP服务器和请求客户端之间链接的窃听者可以发现此LCI。
To minimize the unintended exposure of location information, the LCI option SHOULD be returned by DHCP servers only when the DHCP client has included this option in its 'parameter request list' (Section 3.5 of [RFC2131], Section 9.8 of [RFC2132]).
为了尽量减少位置信息的意外暴露，只有当DHCP客户端在其“参数请求列表”（RFC2131第3.5节，[RFC2132]第9.8节）中包含此选项时，DHCP服务器才应返回LCI选项。
Where critical decisions might be based on the value of this option, DHCP authentication as defined in "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP options.
如果关键决策可能基于此选项的值，则应使用“DHCP消息身份验证”[RFC3118]和“IPv6动态主机配置协议（DHCPv6）”[RFC3315]中定义的DHCP身份验证来保护DHCP选项的完整性。
Link-layer confidentiality and integrity protection may also be employed to reduce the risk of location disclosure and tampering.
链路层机密性和完整性保护也可用于降低位置泄露和篡改的风险。
This document defines the DHCPv6 GeoLoc Option (see Section 2.1), which has been assigned a DHCPv6 option code of 63 per [RFC3315]:
本文件定义了DHCPv6 GeoLoc选项（见第2.1节），该选项已按照[RFC3315]分配了63的DHCPv6选项代码：
Value Description Reference
---- ------------------ ----------
63 OPTION_GEOLOCATION RFC 6225
Value Description Reference
---- ------------------ ----------
63 OPTION_GEOLOCATION RFC 6225
This document defines the DHCPv4 GeoConf Option (see Section 2.2.1), which has been assigned a DHCPv4 option code of 123 from the DHCP Option space.
本文档定义了DHCPv4 GeoConf选项（参见第2.2.1节），该选项已从DHCP选项空间分配了DHCPv4选项代码123。
This document also defines the DHCPv4 GeoLoc Option (see Section 2.2.2), which has been assigned a DHCPv4 option code of 144 per [RFC2132] [RFC2939]:
本文件还定义了DHCPv4 GeoLoc选项（见第2.2.2节），该选项已按照[RFC2132][RFC2939]分配了144的DHCPv4选项代码：
Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
144 GeoLoc 16 Geospatial Location RFC 6225
with Uncertainty
Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
144 GeoLoc 16 Geospatial Location RFC 6225
with Uncertainty
IANA has created and now maintains the Altitude Type registry following the guidelines below.
IANA已按照以下指南创建并维护高度类型注册表。
The registry consists of three values: Altitude Type, Description, and Reference. These are described below.
注册表由三个值组成：高度类型、说明和参考。下文对这些问题进行了说明。
Altitude Type: An integer, refers to the value used in the DHCPv4 GeoConf and the DHCPv4 and DHCPv6 GeoLoc options described in this document. Values 0 - 2 are assigned. Values 3 - 15 are Unassigned [RFC5226].
高度类型：整数，指本文档中描述的DHCPv4 GeoConf以及DHCPv4和DHCPv6 GeoLoc选项中使用的值。将指定值0-2。值3-15未赋值[RFC5226]。
Description: The description of the altitude described by this code.
描述：此代码描述的高度描述。
Reference: The reference to the document that describes the altitude code. This reference MUST define the way that the 30-bit altitude values and the associated 6-bit uncertainty are interpreted.
参考：对描述高度代码的文件的参考。该参考必须定义30位高度值和相关6位不确定性的解释方式。
Initial values are given below; new assignments are to be made following the "Standards Action" policies [RFC5226].
初始值如下所示；按照“标准行动”政策[RFC5226]进行新的分配。
+------+---------------------+--------------+
| # | Description | Reference |
+------+---------------------+--------------+
| 0 | No known altitude | RFC 6225 |
| 1 | Altitude in meters | RFC 6225 |
| 2 | Altitude in floors | RFC 6225 |
| 3-15 | Unassigned | |
+------+---------------------+--------------+
+------+---------------------+--------------+
| # | Description | Reference |
+------+---------------------+--------------+
| 0 | No known altitude | RFC 6225 |
| 1 | Altitude in meters | RFC 6225 |
| 2 | Altitude in floors | RFC 6225 |
| 3-15 | Unassigned | |
+------+---------------------+--------------+
IANA has created and now maintains the Datum registry following the guidelines below.
IANA已经按照以下指南创建并维护了数据注册中心。
The registry consists of three values: Datum, Description, and Reference. These are described below.
注册表由三个值组成：基准、描述和参考。下文对这些问题进行了说明。
Datum: An integer, refers to the value used in the DHCPv4 GeoConf and the DHCPv4 and DHCPv6 GeoLoc options described in this document. Value 0 is Reserved. Values 1 - 3 are assigned. Values 4 - 7 are Unassigned [RFC5226].
Datum：一个整数，指本文档中描述的DHCPv4 GeoConf以及DHCPv4和DHCPv6 GeoLoc选项中使用的值。保留值0。赋值为1-3。值4-7未赋值[RFC5226]。
Description: The description of the altitude described by this code.
描述：此代码描述的高度描述。
Reference: The reference to the document that describes the Datum code. This reference MUST include specification of both the horizontal and vertical datum, and MUST define the way that the 34-bit values and the respective 6-bit uncertainties are interpreted.
参考：对描述基准代码的文件的参考。该参考必须包括水平和垂直基准的规范，并且必须定义34位值和相应6位不确定性的解释方式。
Initial values are given below; new assignments are to be made following the "Standards Action" policies [RFC5226].
初始值如下所示；按照“标准行动”政策[RFC5226]进行新的分配。
+------+----------------------------------------+--------------+
| # | Description | Reference |
+------+----------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+----------------------------------------+--------------+
| 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 |
| | CRS Code 4327 | |
+------+----------------------------------------+--------------+
| 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with North American | |
| | Vertical Datum of 1988 (NAVD88) | |
+------+----------------------------------------+--------------+
| 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with Mean Lower Low Water| |
| | (MLLW) as associated vertical datum | |
+------+----------------------------------------+--------------+
| 4-7 | Unassigned | |
+------+----------------------------------------+--------------+
+------+----------------------------------------+--------------+
| # | Description | Reference |
+------+----------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+----------------------------------------+--------------+
| 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 |
| | CRS Code 4327 | |
+------+----------------------------------------+--------------+
| 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with North American | |
| | Vertical Datum of 1988 (NAVD88) | |
+------+----------------------------------------+--------------+
| 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with Mean Lower Low Water| |
| | (MLLW) as associated vertical datum | |
+------+----------------------------------------+--------------+
| 4-7 | Unassigned | |
+------+----------------------------------------+--------------+
IANA has created and now maintains the GeoLoc Option Version registry following the guidelines below.
IANA已按照以下指南创建并维护GeoLoc选项版本注册表。
The registry consists of three values: GeoLoc Option Version, Description, and Reference. These are described below.
注册表由三个值组成：GeoLoc选项版本、描述和引用。下文对这些问题进行了说明。
GeoLoc Option Version: An integer; refers to the version used in the DHCPv4 and DHCPv6 GeoLoc options described in this document. Value 0 is Reserved. Value 1 has been assigned. Values 2 - 3 are Unassigned [RFC5226].
GeoLoc选项版本：一个整数；指本文档中描述的DHCPv4和DHCPv6 GeoLoc选项中使用的版本。保留值0。已指定值1。值2-3未赋值[RFC5226]。
Description: The description of the version described by this code.
描述：此代码描述的版本的描述。
Reference: The reference to the document that describes the Version code.
引用：对描述版本代码的文档的引用。
Initial values are given below; new assignments are to be made following the "Standards Action" policies [RFC5226].
初始值如下所示；按照“标准行动”政策[RFC5226]进行新的分配。
+------+---------------------------------------+--------------+
| # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+---------------------------------------+--------------+
| 1 | Implementations utilizing uncertainty | RFC 6225 |
| | parameters for both DHCPv4 and DHCPv6 | |
| | GeoLoc options | |
+------+---------------------------------------+--------------+
| 2-3 | Unassigned | |
+------+---------------------------------------+--------------+
+------+---------------------------------------+--------------+
| # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+---------------------------------------+--------------+
| 1 | Implementations utilizing uncertainty | RFC 6225 |
| | parameters for both DHCPv4 and DHCPv6 | |
| | GeoLoc options | |
+------+---------------------------------------+--------------+
| 2-3 | Unassigned | |
+------+---------------------------------------+--------------+
The authors would like to thank Randall Gellens, Patrik Falstrom, Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks, Nadine Abbott, and Mykyta Yevstifeyev for their inputs and constructive comments regarding this document. Additionally, the authors would like to thank Greg Troxel for the education on vertical datums, as well as Carl Reed. Thanks to Richard Barnes for his contribution on GML mapping for resolution.
作者感谢Randall Gellens、Patrik Falstrom、Ralph Droms、Ted Hardie、Jon Peterson、Robert Sparks、Nadine Abbott和Mykyta Yevstifeyev对本文件的投入和建设性意见。此外，作者还要感谢Greg Troxel以及Carl Reed对垂直基准面的教育。感谢Richard Barnes在GML映射分辨率方面的贡献。
[EPSG] European Petroleum Survey Group, <http://www.epsg.org/> and <http://www.epsg-registry.org/>.
[EPSG]欧洲石油调查集团<http://www.epsg.org/>及<http://www.epsg-registry.org/>.
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939]Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.，Ed.，和W.Arbaugh，Ed.，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[WGS84] US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000, <https://www1.nga.mil/PRODUCTSSERVICES/ GEODESYGEOPHYSICS/WORLDGEODETICSYSTEM/ Pages/default.aspx> and <http://www.ngs.noaa.gov/faq.shtml#WGS84>.
[WGS84]美国国家图像和测绘局，“国防部1984年世界大地测量系统（WGS 84），第三版”，NIMA TR8350.22000年1月<https://www1.nga.mil/PRODUCTSSERVICES/ 大地测量地球物理学/WorldGeometricSystem/Pages/default.aspx>和<http://www.ngs.noaa.gov/faq.shtml#WGS84>.
[Convey] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, May 2011.
[传达]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传递”，正在进行的工作，2011年5月。
[GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142, Version: 0.0.9, December 2006.
[GeoShape]Thomson，M.和C.Reed，“互联网工程任务组（IETF）使用的GML 3.1.1 PIDF-LO形状应用模式”，候选OpenGIS实施规范06-142，版本：0.0.92006年12月。
[IEEE-802.11y] IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 3: 3650-3700 MHz Operation in USA, November 2008.
[IEEE-802.11y]IEEE信息技术标准-系统间远程通信和信息交换-局域网和城域网-特定要求-第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范修订3:3650-3700 MHz在美国的运行，2008年11月。
[NENA] National Emergency Number Association (NENA), NENA Technical Information Document on Model Legislation Enhanced 911 for Multi-Line Telephone Systems, <www.nena.org>.
[NENA]国家紧急电话号码协会（NENA），NENA关于多线电话系统增强型911示范立法的技术信息文件，<www.NENA.org>。
[OGC-GML3.1.1] Portele, C., Cox, S., Daisy, P., Lake, R., and A. Whiteside, "Geography Markup Language (GML) 3.1.1", OGC 03-105r1, July 2003.
[OGC-GML3.1.1]Portele，C.，Cox，S.，Daisy，P.，Lake，R.，和A.Whiteside，“地理标记语言（GML）3.1.1”，OGC 03-105r1，2003年7月。
[OGP.Geodesy] International Association of Oil & Gas Producers (OGP) Geodesy Resources, Geomatics Committee, <http://info.ogp.org.uk/geodesy/>.
[OGP.大地测量学]国际石油天然气生产商协会（OGP）大地测量资源，地球测量学委员会<http://info.ogp.org.uk/geodesy/>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[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月。
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3694]Danley，M.，Mulligan，D.，Morris，J.，和J.Peterson，“Geopriv协议的威胁分析”，RFC 3694，2004年2月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825]Polk，J.，Schnizlein，J.，和M.Linsner，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 38252004年7月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776]Schulzrinne，H.，“Civic地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 4776，2006年11月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]Thomson，M.和J.Winterbottom，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 5139，2008年2月。
[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月。
The GML representation of a decoded DHCP option depends on what fields are specified. The DHCP format for location logically describes a geodetic prism, rectangle, or point, depending on whether altitude and uncertainty values are provided. In the absence of uncertainty information, the value decoded from the DHCP form can be expressed as a single point; this is true regardless of whether the version 0 or version 1 interpretations of the uncertainty fields are used. If the point includes altitude, it uses a three-dimensional Coordinate Reference System (CRS); otherwise, it uses a two-dimensional CRS. If all fields are included along with uncertainty, the shape described is a rectangular prism. Note that this is necessary given that uncertainty for each axis is provided independently.
解码DHCP选项的GML表示取决于指定的字段。位置的DHCP格式从逻辑上描述了大地测量棱镜、矩形或点，具体取决于是否提供了高度和不确定度值。在没有不确定性信息的情况下，从DHCP形式解码的值可以表示为单个点；无论是否使用不确定性字段的版本0或版本1解释，这都是正确的。如果该点包括高度，则使用三维坐标系（CRS）；否则，它使用二维CRS。如果所有场都包含在不确定性中，则描述的形状为矩形棱镜。请注意，鉴于每个轴的不确定性是独立提供的，因此这是必要的。
If altitude or altitude uncertainty (AltUnc) is not specified, the shape is described as a rectangle using the "gml:Polygon" shape. If altitude is available, a three-dimensional CRS is used; otherwise, a two-dimensional CRS is used.
如果未指定高度或高度不确定性（AltUnc），则使用“gml:多边形”形状将形状描述为矩形。如果高度可用，则使用三维CRS；否则，使用二维CRS。
For Datum values of 2 or 3 (NAD83), there is no available CRS URN that covers three-dimensional coordinates. By necessity, locations described in these datums can be represented by two-dimensional shapes only; that is, either a two-dimensional point or a polygon.
对于2或3（NAD83）的基准值，没有覆盖三维坐标的可用CRS URN。根据需要，这些基准中描述的位置只能用二维形状表示；即，二维点或多边形。
If the Altitude Type is 2 (floors), then this value can be represented using a civic address object [RFC5139] that is presented alongside the geodetic object.
如果高度类型为2（楼层），则该值可以使用在大地测量对象旁边显示的civic address对象[RFC5139]表示。
This Appendix describes how the location value encoded in DHCP format for geodetic location can be expressed in GML. The mapping is valid for the DHCPv6 GeoLoc Option as well as both of the DHCPv4 GeoConf and GeoLoc options, and for the currently defined datum values (1, 2, and 3). Further version or datum definitions should provide similar mappings.
本附录描述了如何用GML表示大地测量位置的DHCP格式编码的位置值。该映射对DHCPv6 GeoLoc选项、DHCPv4 GeoConf和GeoLoc选项以及当前定义的基准值（1、2和3）有效。进一步的版本或基准定义应提供类似的映射。
These shapes can be mapped to GML by first computing the bounds that are described using the coordinate and uncertainty fields, then encoding the result in a GML Polygon or Prism shape.
通过首先计算使用坐标和不确定性字段描述的边界，然后将结果编码为GML多边形或棱柱形，可以将这些形状映射到GML。
If altitude is provided in meters (AType 1) and the datum value is WGS84 (value 1), then the proper GML shape is a Prism, with the following form (where $value$ indicates a value computed from the DHCP option as described below):
如果高度以米为单位提供（类型1），且基准值为WGS84（值1），则正确的GML形状为棱镜，其形式如下（其中$value$表示根据DHCP选项计算的值，如下所述）：
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $lowLongitude$ $lowAltitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$highAltitude - lowAltitude$
</gs:height>
</gs:Prism>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $lowLongitude$ $lowAltitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$highAltitude - lowAltitude$
</gs:height>
</gs:Prism>
The Polygon shape is used if altitude is omitted or specified in floors, or if either NAD83 datum is used (value 2 or 3). The corresponding GML Polygon has the following form:
如果楼层中省略或指定了高度，或者使用了NAD83基准面（值2或3），则使用多边形形状。相应的GML多边形具有以下形式：
<gml:Polygon srsName="$2D-CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$
$lowLatitude$ $highLongitude$
$highLatitude$ $highLongitude$
$highLatitude$ $lowLongitude$
$lowLatitude$ $lowLongitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
<gml:Polygon srsName="$2D-CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$
$lowLatitude$ $highLongitude$
$highLatitude$ $highLongitude$
$highLatitude$ $lowLongitude$
$lowLatitude$ $lowLongitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
The value "2D-CRS-URN" is defined by the datum value: If the datum is WGS84 (value 1), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4326". If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4269".
值“2D-CRS-URN”由基准值定义：如果基准为WGS84（值1），则2D-CRS-URN为“URN:ogc:def:CRS:EPSG:：4326”。如果基准为NAD83（值2或3），则2D-CRS-URN为“URN:ogc:def:CRS:EPSG:：4269”。
A Polygon shape with the WGS84 three-dimensional CRS is used if the datum is WGS84 (value 1) and the altitude is specified in meters (Altitude Type 1), but no altitude uncertainty is specified (that is, AltUnc is 0). In this case, the value of the Altitude field is added after each of the points above, and the srsName attribute is set to the three-dimensional WGS84 CRS, namely "urn:ogc:def:crs:EPSG::4979".
如果基准为WGS84（值1），高度以米为单位（高度类型1），但未指定高度不确定性（即AltUnc为0），则使用带有WGS84三维CRS的多边形形状。在这种情况下，将高度字段的值添加到上述每个点之后，并将srsName属性设置为三维WGS84 CRS，即“urn:ogc:def:CRS:EPSG:：4979”。
A simple point shape is used if either latitude uncertainty (LatUnc) or longitude uncertainty (LongUnc) is not specified. With altitude, this uses a three-dimensional CRS; otherwise, it uses a two-dimensional CRS.
如果未指定纬度不确定性（LatUnc）或经度不确定性（LongUnc），则使用简单的点形状。对于高度，这使用了三维CRS；否则，它使用二维CRS。
<gml:Point srsName="$CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos>
</gml:Point>
<gml:Point srsName="$CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos>
</gml:Point>
For the DHCPv4 GeoConf Option 123, resolution fields are used (LaRes, LoRes, AltRes), indicating how many bits of a value contain information. Any bits beyond those indicated can be either zero or one.
对于DHCPv4 GeoConf选项123，使用分辨率字段（LaRes、LoRes、AltRes），指示值的多少位包含信息。超出指示的任何位可以是零或一。
For the DHCPv6 GeoLoc Option 63 and DHCPv4 GeoLoc Option 144, the LatUnc, LongUnc, and AltUnc fields indicate uncertainty distances, denoting the bounds of the location region described by the DHCP location object.
对于DHCPv6 GeoLoc选项63和DHCPv4 GeoLoc选项144，LatUnc、LongUnc和AltUnc字段表示不确定距离，表示DHCP位置对象描述的位置区域的边界。
The two sections below describe how to compute the latitude, longitude, and altitude bounds (e.g., $lowLatitude$, $highAltitude$) in the templates above. The first section describes how these bounds are computed in the "resolution encoding" (DHCPv4 GeoConf Option 123), while the second section addresses the "uncertainty encoding" (DHCPv6 GeoLoc Option 63 and DHCPv4 GeoLoc Option 144).
下面的两个部分描述了如何在上面的模板中计算纬度、经度和海拔边界（例如，$lowLatitude$，$highAltitude$）。第一节描述如何在“分辨率编码”（DHCPv4 GeoConf选项123）中计算这些边界，而第二节讨论“不确定性编码”（DHCPv6 GeoLoc选项63和DHCPv4 GeoLoc选项144）。
Given a number of resolution bits (i.e., the value of a resolution field), if all bits beyond those bits are set to zero, this gives the lowest possible value. The highest possible value can be found setting all bits to one.
给定一定数量的分辨率位（即，分辨率字段的值），如果超过这些位的所有位都设置为零，则会给出最低的可能值。将所有位设置为1可以找到可能的最高值。
If the encoded value of latitude/longitude and resolution (LaRes, LoRes) are treated as 34-bit unsigned integers, the following can be used (where ">>" is a bitwise right shift, "&" is a bitwise AND, "~" is a bitwise negation, and "|" is a bitwise OR).
如果纬度/经度和分辨率（LaRes，LoRes）的编码值被视为34位无符号整数，则可以使用以下内容（其中“>>”是按位右移，&”是按位右移，“~”是按位求反，“|”是按位OR）。
mask = 0x3ffffffff >> resolution
lowvalue = value & ~mask
highvalue = value | mask + 1
mask = 0x3ffffffff >> resolution
lowvalue = value & ~mask
highvalue = value | mask + 1
Once these values are determined, the corresponding floating-point numbers can be computed by dividing the values by 2^25 (since there are 25 bits of fraction in the fixed-point representation).
一旦确定了这些值，就可以通过将这些值除以2^25来计算相应的浮点数（因为在定点表示中有25位小数）。
Alternatively, the lowest possible value can be found by using resolution to determine the size of the range. This method has the advantage that it operates on the decoded floating-point values. It is equivalent to the first mechanism, to a possible error of 2^-25 (2^-8 for altitude).
或者，可以通过使用分辨率确定范围的大小来找到可能的最低值。这种方法的优点是它对解码的浮点值进行操作。它相当于第一个机构，可能的误差为2^-25（高度为2^-8）。
scale = 2 ^ ( 9 - resolution )
lowvalue = floor( value / scale ) * scale
highvalue = lowvalue + scale
scale = 2 ^ ( 9 - resolution )
lowvalue = floor( value / scale ) * scale
highvalue = lowvalue + scale
Altitude resolution (AltRes) uses the same process with different constants. There are 22 whole bits in the altitude encoding (instead of 9) and 30 bits in total (instead of 34).
高度分辨率（AltRes）使用相同的过程和不同的常数。高度编码中有22个整位（而不是9位），总共有30位（而不是34位）。
In the uncertainty encoding, the uncertainty fields (LongUnc/LatUnc) directly represent the logarithms of uncertainty distances. So the low and high bounds are computed by first computing the uncertainty distances, then adding and subtracting these from the value provided. If "uncertainty" is the unsigned integer value of the uncertainty field and "value" is the value of the coordinate field:
在不确定性编码中，不确定性字段（LongUnc/LatUnc）直接表示不确定性距离的对数。因此，通过首先计算不确定性距离，然后从提供的值中加上或减去这些距离，来计算下限和上限。如果“不确定度”是不确定度字段的无符号整数值，“值”是坐标字段的值：
distance = 2 ^ (8 - uncertainty)
lowvalue = value - distance
highvalue = value + distance
distance = 2 ^ (8 - uncertainty)
lowvalue = value - distance
highvalue = value + distance
Altitude uncertainty (AltUnc in version 1) uses the same process with different constants:
高度不确定性（版本1中的AltUnc）使用相同的过程和不同的常数：
distance = 2 ^ (21 - uncertainty)
lowvalue = value - distance
distance = 2 ^ (21 - uncertainty)
lowvalue = value - distance
The following examples for two different locations demonstrate how the resolution values for latitude, longitude, and altitude (used in DHCPv4 GeoConf Option 123) can be calculated. In both examples, the geo-location values were derived from maps using the WGS84 map datum; therefore, in these examples, the Datum field would have a value = 1 (00000001, or 0x01).
以下两个不同位置的示例演示了如何计算纬度、经度和高度的分辨率值（在DHCPv4 GeoConf选项123中使用）。在这两个示例中，地理位置值都是使用WGS84地图基准从地图中得出的；因此，在这些示例中，基准字段的值为1（00000001或0x01）。
The grounds of the White House in Washington D.C. (1600 Pennsylvania Ave. NW, Washington, DC 20006) can be found between 38.895375 and 38.898653 degrees North and 77.037911 and 77.035116 degrees West. In this example, we assume that we are standing on the sidewalk on the north side of the White House, between driveways. Since we are not inside a structure, we assume an altitude value of 15 meters, interpolated from the US Geological survey map, Washington, Washington West quadrangle.
华盛顿特区的白宫（华盛顿特区西北宾夕法尼亚大道1600号，20006年）位于北纬38.895375度和38.898653度之间，西经77.037911度和77.035116度之间。在这个例子中，我们假设我们站在白宫北侧车道之间的人行道上。由于我们不在建筑物内，我们假设高度值为15米，根据美国地质调查局地图，华盛顿，华盛顿西四合院插值。
The address was NOT picked for any political reason and can easily be found on the Internet or mapping software, but was picked as an easily identifiable location on our planet.
该地址并非出于任何政治原因而选择的，可以在互联网或地图软件上轻松找到，但被选为我们星球上一个易于识别的位置。
In this example, the requirement of emergency responders in North America via their National Emergency Number Association (NENA) Model Legislation [NENA] could be met by a LaRes value of 21 and a LoRes value of 20. This would yield a geo-location that is latitude 38.8984375 north to latitude 38.8988616 north and longitude -77.0371094 to longitude -77.0375977. This is an area of approximately 89 feet by 75 feet or 6669 square feet, which is very close to the 7000 square feet requested by NENA. In this example, a service provider could enforce that a device send location configuration information with this minimum amount of resolution for this particular location when calling emergency services.
在本例中，北美应急响应人员通过其国家应急号码协会（NENA）示范立法[NENA]的要求可以通过LaRes值21和LoRes值20得到满足。这将产生一个地理位置，即北纬38.8984375至北纬38.8988616，经度-77.0371094至经度-77.0375977。这一面积约为89英尺乘75英尺或6669平方英尺，非常接近NENA要求的7000平方英尺。在此示例中，服务提供商可以强制设备在调用紧急服务时，以此特定位置的最小分辨率发送位置配置信息。
An approximate representation of this location might be provided using the DHCPv4 GeoConf Option 123 encoding as follows:
可使用DHCPv4 GeoConf选项123编码提供该位置的近似表示，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (123) | OptLen (16) | LaRes | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|0 0 0 1 0 0 1 1 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LoRes | .
.1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 1|0 1 0 0 0 1|1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) |
.0 1 1 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 0 0 0 0 1 0 1 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude .
|0 0 0 1|0 1 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Alt (cont'd) | Res |Datum|
.0 0 0 0 0 0 0 0|0 0 0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (123) | OptLen (16) | LaRes | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|0 0 0 1 0 0 1 1 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LoRes | .
.1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 1|0 1 0 0 0 1|1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) |
.0 1 1 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 0 0 0 0 1 0 1 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude .
|0 0 0 1|0 1 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Alt (cont'd) | Res |Datum|
.0 0 0 0 0 0 0 0|0 0 0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In hexadecimal, this is 7B10484D CB986347 65ED42C4 1440000F 0001.
以十六进制表示，这是7B10484D CB986347 65ED42C4 1440000F 0001。
Decoding this option gives a latitude of 38.897647 (to 7 decimal places) with 18 bits of resolution, a longitude of -77.0366000 with 17 bits of resolution, an Altitude Type of meters with a value of 15 and 17 bits of resolution, version 0 (resolution), and the WGS84 datum.
对该选项进行解码时，纬度为38.897647（至小数点后7位），分辨率为18位；经度为-77.0366000，分辨率为17位；高度类型为米，分辨率为15位和17位；版本0（分辨率）和WGS84基准。
For the latitude value, 18 bits of resolution allow for values in the range from 38.8964844 to 38.8984375. For the longitude value, 17 bits of resolution allow for values in the range from -77.0390625 to -77.0351563. Having 17 bits of resolution in the altitude allows for values in the range from 0 to 32 meters.
对于纬度值，18位分辨率允许38.8964844到38.8984375范围内的值。对于经度值，17位分辨率允许-77.0390625到-77.0351563范围内的值。高度分辨率为17位时，允许值的范围为0到32米。
The following GML shows the value decoded in the previous example as a point in a three-dimensional CRS:
以下GML显示了在前一示例中解码的值作为三维CRS中的一个点：
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>38.897647 -77.0366 15</gml:pos>
</gml:Point>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>38.897647 -77.0366 15</gml:pos>
</gml:Point>
This representation ignores the values included in the resolution parameters. If resolution values are provided, a rectangular prism can be used to represent the location.
此表达将忽略分辨率参数中包含的值。如果提供了分辨率值，则可以使用矩形棱镜表示位置。
The following example uses all of the decoded information from the previous example:
以下示例使用上一示例中的所有解码信息：
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
38.8964844 -77.0390625 0
38.8964844 -77.0351563 0
38.8984375 -77.0351563 0
38.8984375 -77.0390625 0
38.8964844 -77.0390625 0
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
32
</gs:height>
</gs:Prism>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
38.8964844 -77.0390625 0
38.8964844 -77.0351563 0
38.8984375 -77.0351563 0
38.8984375 -77.0390625 0
38.8964844 -77.0390625 0
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
32
</gs:height>
</gs:Prism>
Postal Address: Sears Tower 103rd Floor 233 S. Wacker Dr. Chicago, IL 60606
邮政地址：伊利诺伊州芝加哥市S.Wacker博士233号西尔斯大厦103楼60606
Viewing the Chicago area from the Observation Deck of the Sears Tower:
从西尔斯大厦的观景台观看芝加哥地区：
Latitude 41.87884 degrees North (or +41.87884 degrees)
Using two's complement, 34-bit fixed point, 25 bits of fraction
Latitude = 0x053c1f751,
Latitude = 0001010011110000011111011101010001
Longitude 87.63602 degrees West (or -87.63602 degrees)
Using two's complement, 34-bit fixed point, 25 bits of fraction
Longitude = 0xf50ba5b97,
Longitude = 1101010000101110100101101110010111
Latitude 41.87884 degrees North (or +41.87884 degrees)
Using two's complement, 34-bit fixed point, 25 bits of fraction
Latitude = 0x053c1f751,
Latitude = 0001010011110000011111011101010001
Longitude 87.63602 degrees West (or -87.63602 degrees)
Using two's complement, 34-bit fixed point, 25 bits of fraction
Longitude = 0xf50ba5b97,
Longitude = 1101010000101110100101101110010111
Altitude 103
海拔103
In this example, we are inside a structure; therefore, we will assume an altitude value of 103 to indicate the floor we are on. The Altitude Type value is 2, indicating floors. The AltRes field would indicate that all bits in the Altitude field are true, as we want to accurately represent the floor of the structure where we are located.
在这个例子中，我们在一个结构中；因此，我们将假设高度值为103，以指示我们所在的楼层。“高度类型”值为2，表示楼层。AltRes字段将指示高度字段中的所有位均为真，因为我们希望准确表示我们所在结构的楼层。
AltRes = 30, 0x1e, 011110 AType = 2, 0x02, 000010 Altitude = 103, 0x00006700, 000000000000000110011100000000
AltRes=30，0x1e，011110 AType=2，0x02，000010高度=103，0x00006700000000000 110011100000000
For the accuracy of the latitude and longitude, the best information available to us was supplied by a generic mapping service that shows a single geo-loc for all of the Sears Tower. Therefore, we are going to show LaRes as value 18 (0x12 or 010010) and LoRes as value 18 (0x12 or 010010). This would be describing a geo-location area that is latitude 41.8769531 to latitude 41.8789062 and extends from -87.6367188 degrees to -87.6347657 degrees longitude. This is an area of approximately 373412 square feet (713.3 ft. x 523.5 ft.).
对于纬度和经度的准确性，我们所能获得的最佳信息是由通用地图服务提供的，该服务显示所有西尔斯塔的单一地理位置。因此，我们将LaRes显示为值18（0x12或010010），LoRes显示为值18（0x12或010010）。这将描述纬度41.8769531至纬度41.8789062，并从-87.6367188度延伸至-87.6347657度经度的地理位置区域。面积约为373412平方英尺（713.3英尺x 523.5英尺）。
The following example demonstrates how uncertainty values for latitude, longitude, and altitude (LatUnc, LongUnc, and AltUnc used in the DHCPv6 GeoLoc Option 63 as well as DHCPv4 GeoLoc Option 144) can be calculated.
以下示例演示如何计算纬度、经度和高度（DHCPv6 GeoLoc选项63以及DHCPv4 GeoLoc选项144中使用的纬度、经度和高度）的不确定性值。
C.1. Location Configuration Information of "Sydney Opera House" (Example 3)
C.1. “悉尼歌剧院”的位置配置信息（示例3）
This section describes an example of encoding and decoding the geodetic DHCP Option. The textual results are expressed in GML [OGC-GML3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119].
本节描述编码和解码大地测量DHCP选项的示例。文本结果以GML[OGC-GML3.1.1]形式表示，适合包含在PIDF-LO[RFC4119]中。
These examples all assume a datum of WGS84 (datum = 1) and an Altitude Type of meters (AType = 1).
这些示例均假定基准为WGS84（基准=1）和高度类型为米（AType=1）。
This example draws a rough polygon around the Sydney Opera House. This polygon consists of the following six points:
此示例围绕悉尼歌剧院绘制一个粗糙多边形。该多边形由以下六个点组成：
33.856625 S, 151.215906 E 33.856299 S, 151.215343 E 33.856326 S, 151.214731 E 33.857533 S, 151.214495 E 33.857720 S, 151.214613 E 33.857369 S, 151.215375 E
33.856625 S、151.215906 E 33.856299 S、151.215343 E 33.856326 S、151.214731 E 33.857533 S、151.214495 E 33.857720 S、151.214613 E 33.857369 S、151.215375 E
The top of the building is 67.4 meters above sea level, and a starting altitude of 0 meters above the WGS84 geoid is assumed.
建筑物顶部高于海平面67.4米，假设起始高度高于WGS84大地水准面0米。
The first step is to determine the range of latitude and longitude values. Latitude ranges from -33.857720 to -33.856299; longitude ranges from 151.214495 to 151.215906.
第一步是确定纬度和经度值的范围。纬度范围从-33.857720到-33.856299；经度范围从151.214495到151.215906。
For this example, the point that is encoded is chosen by finding the middle of each range, that is (-33.8570095, 151.2152005). This is encoded as (1110111100010010010011011000001101, 0100101110011011100010111011000011) in binary, or (3BC49360D, 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading padding on each). Altitude is set at 33.7 meters, which is 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal).
对于本例，通过查找每个范围的中间值来选择编码的点，即（-33.8570095151.215205）。它以二进制编码为（1110111110001001001001001010100101110011011100010111011000011），或以十六进制表示法（3BC49360D，12E6E2EC3）编码为（11101111100100100110110000011，0100101110011011100010111011000011）（每个上有额外的2位前导填充）。高度设置为33.7米，即0000000000000000 1000010110011（二进制）或000021B3（十六进制）。
The latitude uncertainty (LatUnc) is given by inserting the difference between the center value and the outer value into the formula from Section 2.3.2. This gives:
纬度不确定度（LatUnc）是通过将中心值和外部值之间的差值插入第2.3.2节的公式中得出的。这使得：
x = 8 - ceil( log2( -33.8570095 - -33.857720 ) )
x = 8 - ceil( log2( -33.8570095 - -33.857720 ) )
The result of this equation is 18; therefore, the uncertainty is encoded as 010010 in binary.
这个方程的结果是18；因此，不确定度以二进制编码为010010。
Similarly, longitude uncertainty (LongUnc) is given by the formula:
类似地，经度不确定度（LongUnc）由以下公式给出：
x = 8 - ceil( log2( 151.2152005 - 151.214495 ) )
x = 8 - ceil( log2( 151.2152005 - 151.214495 ) )
The result of this equation is also 18, or 010010 in binary.
这个方程的结果也是18，或二进制的010010。
Altitude uncertainty (AltUnc) uses the formula from Section 2.4.5:
高度不确定性（AltUnc）使用第2.4.5节中的公式：
x = 21 - ceil( log2( 33.7 - 0 ) )
x = 21 - ceil( log2( 33.7 - 0 ) )
The result of this equation is 15, which is encoded as 001111 in binary.
该方程的结果为15，二进制编码为001111。
Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this gives the following DHCPv4 GeoLoc Option 144 form:
添加1（米）的高度类型和1（WGS84）的基准面后，将得到以下DHCPv4 GeoLoc选项144表格：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (144) | OptLen (16) | LatUnc | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LongUnc | .
.0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) |
.0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude .
|0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Alt (cont'd) |Ver| Res |Datum|
.1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (144) | OptLen (16) | LatUnc | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LongUnc | .
.0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) |
.0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude .
|0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Alt (cont'd) |Ver| Res |Datum|
.1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341. The DHCPv6 form only differs in the code and option length portion.
以十六进制表示，这是7B104BBC 49360D49 2E6E2EC3 13C00021 B341。DHCPv6表单仅在代码和选项长度部分有所不同。
If receiving the binary form created in the previous section, this section describes how that would be interpreted. The result is then represented as a GML object, as defined in [GeoShape].
如果收到上一节中创建的二进制表单，本节将描述如何解释该表单。然后将结果表示为[GeoShape]中定义的GML对象。
A latitude value of 1110111100010010010011011000001101 decodes to a value of -33.8570095003 (to 10 decimal places). The longitude value of 0100101110011011100010111011000011 decodes to 151.2152005136.
纬度值11101111000010010011011000001101解码为-33.8570095003（小数点后10位）。经度值0100101110011011100010111011000011解码为151.215205136。
Decoding Tip: If the raw values of latitude and longitude are placed in integer variables, the actual value can be derived by the following process:
解码提示：如果纬度和经度的原始值放在整数变量中，则可以通过以下过程导出实际值：
1. If the highest order bit is set (i.e., the number is a two's complement negative), then subtract 2 to the power of 34 (the total number of bits).
1. 如果设置了最高阶位（即，该数字为2的负补码），则将2减去34的幂（位的总数）。
2. Divide the result by 2 to the power of 25 (the number of fractional bits) to determine the final value.
2. 将结果除以2到25的幂（小数位数），以确定最终值。
The same principle can be applied when decoding altitude values, except with different powers of 2 (30 and 8, respectively).
解码高度值时可以应用相同的原理，但2的不同幂次（分别为30和8）除外。
The latitude and longitude uncertainty are both 18, which gives an uncertainty value of 0.0009765625 using the formula from Section 2.3.2. Therefore, the decoded latitude is -33.8570095003 +/- 0.0009765625 (or the range from -33.8579860628 to -33.8560329378) and the decoded longitude is 151.2152005136 +/- 0.0009765625 (or the range from 151.2142239511 to 151.2161770761).
纬度和经度不确定度均为18，使用第2.3.2节中的公式得出的不确定度值为0.0009765625。因此，解码的纬度为-33.8570095003+/-0.0009765625（或从-33.8579860628到-33.8560329378的范围），解码的经度为151.215205136+/-0.0009765625（或从151.2142239511到151.2161770761的范围）。
The encoded altitude of 000000000000000010000110110011 decodes to 33.69921875. The encoded uncertainty of 15 gives a value of 64; therefore, the final uncertainty is 33.69921875 +/- 64 (or the range from -30.30078125 to 97.69921875).
编码高度0000000000000000 1000010110011解码为33.69921875。编码的不确定度为15，其值为64；因此，最终不确定度为33.69921875+/-64（或-30.30078125至97.69921875的范围）。
The following GML shows the value decoded in the previous example as a point in a three-dimensional CRS:
以下GML显示了在前一示例中解码的值作为三维CRS中的一个点：
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-33.8570095003 151.2152005136 33.69921875</gml:pos>
</gml:Point>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-33.8570095003 151.2152005136 33.69921875</gml:pos>
</gml:Point>
The following example uses all of the decoded information from the previous example:
以下示例使用上一示例中的所有解码信息：
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-33.8579860628 151.2142239511 -30.30078125
-33.8579860628 151.2161770761 -30.30078125
-33.8560329378 151.2161770761 -30.30078125
-33.8560329378 151.2142239511 -30.30078125
-33.8579860628 151.2142239511 -30.30078125
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
128
</gs:height>
</gs:Prism>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-33.8579860628 151.2142239511 -30.30078125
-33.8579860628 151.2161770761 -30.30078125
-33.8560329378 151.2161770761 -30.30078125
-33.8560329378 151.2142239511 -30.30078125
-33.8579860628 151.2142239511 -30.30078125
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
128
</gs:height>
</gs:Prism>
Note that this representation is only appropriate if the uncertainty is sufficiently small. [GeoShape] recommends that distances between polygon vertices be kept short. A GML representation like this one is only appropriate where uncertainty is less than 1 degree (an encoded value of 9 or greater).
注意，仅当不确定性足够小时，此表示才适用。[GeoShape]建议多边形顶点之间的距离保持较短。像这样的GML表示仅适用于不确定性小于1度（编码值为9或更大）的情况。
This section lists the major changes between RFC 3825 and this document. Minor changes, including style, grammar, spelling, and editorial changes, are not mentioned here.
本节列出了RFC 3825与本文件之间的主要变更。这里没有提到一些小的变化，包括风格、语法、拼写和编辑方面的变化。
o Section 1 now includes clarifications on wired and wireless uses.
o 第1节现在包括对有线和无线用途的澄清。
o The former Sections 1.2 and 1.3 have been removed. Section 1.2 now defines the concepts of uncertainty and resolution, as well as conversion between the DHCP option formats and PIDF-LO.
o 前1.2和1.3节已删除。第1.2节现在定义了不确定性和分辨率的概念，以及DHCP选项格式和PIDF-LO之间的转换。
o A DHCPv6 GeoLoc Option is now defined (Section 2.1) as well as a new DHCPv4 GeoLoc Option (Section 2.2.2).
o 现在定义了DHCPv6 GeoLoc选项（第2.1节）和新的DHCPv4 GeoLoc选项（第2.2.2节）。
o The former Datum field has been split into three fields: Ver, Res, and Datum. These fields are used in both the DHCPv4 GeoLoc Option and the DHCPv6 GeoLoc Option.
o 以前的基准字段已分为三个字段：Ver、Res和Datum。这些字段用于DHCPv4 GeoLoc选项和DHCPv6 GeoLoc选项。
o Section 2.2.3 has been added, describing option support requirements on DHCP clients and servers.
o 增加了第2.2.3节，描述了DHCP客户端和服务器的选项支持要求。
o Section 2.3 has been added, describing the Latitude and Longitude fields.
o 增加了第2.3节，描述了纬度和经度字段。
o Section 2.3.1 has been added, covering latitude and longitude resolution.
o 增加了第2.3.1节，包括纬度和经度分辨率。
o Section 2.3.2 has been added, covering latitude and longitude uncertainty.
o 增加了第2.3.2节，涵盖纬度和经度不确定性。
o Section 2.4 has been added, covering values of the Altitude field (Sections 2.4.1, 2.4.2, and 2.4.3), altitude resolution (Section 2.4.4), and altitude uncertainty (Section 2.4.5).
o 增加了第2.4节，涵盖了高度场（第2.4.1节、第2.4.2节和第2.4.3节）、高度分辨率（第2.4.4节）和高度不确定性（第2.4.5节）的值。
o Section 2.5 has been added, covering the Datum field.
o 增加了第2.5节，涵盖了基准场。
o Section 3 (Security Considerations) has added a recommendation on link-layer confidentiality.
o 第3节（安全注意事项）增加了关于链路层机密性的建议。
o Section 4 (IANA Considerations) has consolidated material relating to parameter allocation for both the DHCPv4 and DHCPv6 option parameters, and has been rewritten to conform to the practices recommended in RFC 5226.
o 第4节（IANA注意事项）合并了与DHCPv4和DHCPv6选项参数的参数分配相关的材料，并已重写，以符合RFC 5226中建议的实践。
o The material formerly in Appendix A has been updated and shortened and has been moved to Appendix B.
o 原附录A中的材料已更新和缩短，并已移至附录B。
o An Appendix A on GML mapping has been added.
o 增加了关于GML映射的附录A。
o Appendix C has been added, providing an example of uncertainty encoding.
o 增加了附录C，提供了不确定性编码示例。
o Appendix D has been added, detailing the changes from RFC 3825.
o 增加了附录D，详细说明了RFC 3825的变更。
Authors' Addresses
作者地址
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA
詹姆斯·M·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Marc Linsner Cisco Systems Marco Island, FL 34145 USA
Marc Linsner思科系统公司美国佛罗里达州马可岛，邮编34145
EMail: marc.linsner@cisco.com
EMail: marc.linsner@cisco.com
Martin Thomson Andrew Corporation PO Box U40 Wollongong University Campus, NSW 2500 AU
马丁·汤姆森·安德鲁公司邮政信箱U40，新南威尔士州卧龙岗大学校园2500
EMail: martin.thomson@andrew.com
EMail: martin.thomson@andrew.com
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Bernard Aboba（编辑）微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernard_aboba@hotmail.com
EMail: bernard_aboba@hotmail.com