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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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]オプションは、サーバによって提供されるように指定します。 [RFC4776]は市民のアドレスのためのDHCPオプションを指定し、「市民のための動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報がアドレス」。
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クライアントを有効に定義されたオプションを調整します。例えば、有線イーサネットホストは、位置決定のためにこれらのオプションを使用するかもしれません。この場合、位置情報は、RFC 3046 [RFC3046]で定義された回線IDリレーエージェント情報オプション（RAIO）（サブオプション1など）を使用して、DHCPサーバによってワイヤーマップに由来することができます。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
緯度（ラレス）、経度（LORES）、高度（AltRes）解像度フィールドは、6ビットの符号なし整数値として符号化されます。 DHCPv4のGeoConfオプション123においては、ラレス、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.
不確実性は、通常、対象が位置する領域として表されます。この文書では、3つの軸のそれぞれは、不確定値を割り当てることができます。実際には、これは、それに収まるより複雑な形状の粗い表現として使用することができる直角プリズムを、記載されています。形や不確実性との間の対応の詳細については、セクション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は地理マークアップ言語（GML）にDHCPオプション値のマッピングを説明しています。この文書の付録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]は位置および緊急呼内の関連不確実性を伝えるために使用されているので[伝える]、機構はDHCPv4とDHCPv6の内に含まれる情報を変換するために必要とされますPIDF-LOのオプション。このドキュメントでは、次の変換について説明します。
o DHCPv4 GeoConf Option 123 to PIDF-LO
ああdakpp 4 jakamphのpidiphインオプション123付き
o DHCPv4 GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 to PIDF-LO
PIDF-LOに対するOの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への変換は不確実性を増加させません。各次元における2倍未満だけのDHCPv4 GeoLocオプション144とDHCPv6 GeoLocオプション63の増加の不確定性にPIDF-LOの変換。それは不確実で有界増加にDHCP GeoConfオプション123に任意PIDF-LOを変換することは不可能であるので、変換が指定されていません。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
緯度：2.3節に記載されるように解釈整数の9ビット、小数の25ビットからなる34ビットの固定小数点値。
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.
経度：2.3節で説明したように整数の9ビット、小数の25ビットからなる34ビットの固定小数点値は、解釈されます。
AType: 4 bits. Altitude Type, defined in Section 2.4.
Aタイプ：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ビット。場合版フィールド= 1は、このフィールドは高度の不確実性を表します。このフィールドの内容は、Ver分野の他の値のために定義されていません。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：2.4節で説明Aタイプフィールドによって定義される30ビット値。
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.
版：Ver分野は、4つの潜在的なバージョンを提供する、2ビットです。この仕様は、Ver分野が常に同じに関係なく、使用中のバージョンの、オプションの先頭からのオフセットに配置されているバージョン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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ラレス：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.
緯度：2.3節に記載されるように解釈符号付き整数の9ビット、小数の25ビットからなる34ビットの固定小数点値。
LoRes: 6 bits. This field represents longitude resolution.
LORES：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.
経度：2.3節で説明したように符号付き整数の9ビット、小数の25ビットからなる34ビットの固定小数点値は、解釈されます。
AType: 4 bits. Altitude Type, defined in Section 2.4.
Aタイプ：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.
高度：2.4節で説明Aタイプフィールドによって定義される30ビット値。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
緯度：2.3節に記載されるように解釈整数の9ビット、小数の25ビットからなる34ビットの固定小数点値。
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.
経度：2.3節で説明したように整数の9ビット、小数の25ビットからなる34ビットの固定小数点値は、解釈されます。
AType: 4 bits. Altitude Type, defined in Section 2.4.
Aタイプ：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ビット。場合版フィールド= 1は、このフィールドは高度の不確実性を表します。このフィールドの内容は、Ver分野の他の値のために定義されていません。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：2.4節で説明Aタイプフィールドによって定義される30ビット値。
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.
版：Ver分野は、4つの潜在的なバージョンを提供する、2ビットです。この仕様は、Ver分野が常に同じに関係なく、使用中のバージョンの、オプションの先頭からのオフセットに配置されているバージョン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（元々[RFC3825] RFC 3825で定義されている）を受信するサポートするかもしれません。
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クライアントはパラメータ要求リストのオプションを含めることを通じてGeoConfオプション123、GeoLocオプション144、またはその両方を送信するためにDHCPv4サーバを要求します。 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クライアントによって使用されます。要求されたパラメータのリストは、この文書で定義されている各オクテットが有効なDHCPオプションコードであるnオクテットとして指定されています。
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クライアントが基準値を理解していないとき、彼らはそこにあるかどうかに応じて、（欧州石油調査グループ（EPSG）[EPSG] 4326または4979世界測地系1984（WGS84）[WGS84]データムを仮定しなければなりません現在標高値）とに応じて進みます。あまり正確な位置値がどれよりも優れていると仮定すると、これはいくつかの（おそらくより正確で）位置は、クライアントに利用可能であることを確実にします。
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の送信をサポートしなければならないと応答にGeoConfオプション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サーバが応答したGeoConfオプション123、GeoLocオプション144、またはその両方を送信するかどうかを決定するために、DHCPv4のクライアントによって含まれるパラメータの要求リストを尊重すべきです。
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.
正の緯度は北赤道のであり、負の緯度は赤道の南です。正の経度は、グリニッジ子午線の東であり、負（2の補数）経度は西グリニッジ子午線のです。
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の値）は、-90〜90度の範囲外-180〜180小数度緯度値の範囲外の経度の値が無効であると見なされなければなりません。サーバの実装は、選択座標参照系内の無効な値が入るのを防ぐべきです。場所の消費者は、無効な位置座標を無視しなければなりませんし、無効な場所に関連するエラーをログに記録すべきです。
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においては、ラレス値が有効であると見なされなければならない高次緯度ビットの数を符号化します。この制限の右側に入力された任意のビットが有効と見なされてはならないと故意に虚偽、または送信者によってゼロかもしれません。付録Bの例では、解像度フィールドの値が小さいほど、デバイスが位置する領域を増加させることを示しています。ラレスフィールドの2の値は、地球の（付録Bの最初の例を参照）ことを超えない1/6の精度を示しています。ラレスフィールド34の値は、赤道で緯度で約3.11ミリメートルの精度を示しています。
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の値は、地球の（付録Bの最初の例を参照）ことを超えない1/6の精度を示しています。 LORESフィールド34の値は、（赤道で）経度で約2.42ミリメートルの精度を示しています。経度線が極に収束するので、距離が離れて赤道からの位置について（よりよい精度）小さくなっています。
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.
不確実領域内の点は、エンコードされた点であるように選択されます。地域の重心は、多くの場合、適切な選択です。不確実性の値は、その軸上の不確実性の領域の遠い極端に選択された点からの距離とします。これは、各軸上に投影された2次元ポリゴンを示す以下の図に示されています。同図において、「X」が選択されている点をマークします。 「U」でマークされた範囲は、不確実性を示しています。
___ ___________
^ | / |
| | / |
| | / |
U | / |
| | ( |
V | | |
--X | X |
| | `---------.
| | |
| | |
| | |
- `-------------------------'
|---------X---------------|
|<------U------>|
Key
---
V, ^ = vertical arrows, delimiting the vertical uncertainty range. <> = horizontal arrows, delimiting the horizontal uncertainty range.
垂直方向の不確実性の範囲を区切るV、^ =垂直方向の矢印、。 <> =水平方向の不確かさの範囲を区切る水平方向の矢印は、。
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:
「x」は符号化された整数値であり、以下の式に示されるように不確実性の量は、8の電力、より少ない符号化された値に2をとることによって符号化から決定することができます。
uncertainty = 2 ^ ( 8 - x )
不確実性= 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（不確実性））
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.
この値を符号化した結果は、2つの次の利用可能な電力の不確実性の範囲を増加させることに留意されたいです。その後の繰り返しのエンコーディングとデコーディングは、値を変更しないでください。唯一の不確実性を増加させると、関連する信頼が低下していないことを意味します。
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).
標高値を解釈する方法高度タイプ（Aタイプ）の値と選択された基準に依存します。三の高度タイプ値は、この文書で定義されている：不明（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.
高度Typeが1の値を有する場合、高度、垂直基準により設定された零に関連して、メートル単位で測定されます。 ATYPE = 1のため、高度の値は30ビットの固定小数点、22整数ビット及び8小数ビットの2の補数の整数として表現されます。
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ビットの固定小数点、22整数ビット及び8小数ビットの2の補数の整数として表現されます。
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（10進数）上記の値は不定と予約されています。
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.
高度タイプ値（ATYPE = 1）のものである場合、0.0のAltRes値は、未知高度を示すであろう。最も正確な高度はAltResの30多くの値の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.
AltResフィールドは場合ATYPE = 2（フロア）フロア値はDHCP応答に含まれている場合、最大精度に設定する場合、またはATYPE = 0、フロアが知られていないことを示すためにされるべきです。 ATYPE = 2、AltRes = 30、および高度のように符号化された高度= 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 )
不確実性= 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（不確実性））
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.Geodesy]の定義に基づいて、この文書で定義されています。
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".
この基準は、コード4979を持つ、またはURN「：OGC：DEF：CRS：EPSG :: 4979壷」によって、欧州石油調査グループ石油・ガス生産の（EPSG）/国際交流協会（OGP）によって識別されます。高度なしに、この基準は、EPSG / OGPコード4326とURN "：OGC：DEF：CRS：EPSG :: 4326 URN" によって識別されます。
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：このデータは、水平（緯度と経度）の値に加え、1988年の北米垂直データム（NAVD88）垂直データムための北米データム1983（NAD83）の組み合わせを使用しています。
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は、4269のEPSG / OGPコード、またはURN "：OGC：DEF：CRS：EPSG :: 4269壷" によって識別されます。 NAVD88は5703のEPSG / OGPコード、または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：このデータは、水平（緯度と経度）の値、プラス平均低低水（MLLW）垂直データムための北米データム1983（NAD83）の組み合わせを使用しています。
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は、4269のEPSG / OGPコード、または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]).
位置情報の意図しない露出を最小限に抑えるために、LCIオプションは、DHCPクライアントがその「パラメータ要求リスト」（[RFC2131]のセクション3.5、[RFC2132]のセクション9.8）にこのオプションが含まれている場合にのみ、DHCPサーバによって返されるべきです。
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メッセージの認証」で定義されている重要な決定は、このオプション、DHCP認証の値に基づいてされる可能性があります場合は、[RFC3118]および「IPv6の動的ホスト構成プロトコル（DHCPv6）」[RFC3315]はの完全性を保護するために使用されるべき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]:
このドキュメントは[RFC3315]あたり63のDHCPv6オプションコードが割り当てられていたDHCPv6 GeoLocオプション（セクション2.1を参照）、定義されています。
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.
この文書では、DHCPオプションスペースから123のDHCPv4のオプションコードが割り当てられているのDHCPv4 GeoConfオプションを（2.2.1項を参照）、定義されています。
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]:
また、このドキュメントは[RFC2132]、[RFC2939]あたり144のDHCPv4のオプションコードが割り当てられているのDHCPv4 GeoLocオプション（セクション2.2.2を参照）、定義されています。
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.
高度タイプ、説明、およびリファレンス：レジストリは、次の3つの値で構成されています。これらは、以下に記載されています。
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 | |
+------+---------------------+--------------+
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.
データム、説明、およびリファレンス：レジストリは、次の3つの値で構成されています。これらは、以下に記載されています。
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].
基準：整数、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 | |
+------+----------------------------------------+--------------+
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オプションバージョン、説明、およびリファレンス：レジストリは、次の3つの値で構成されています。これらは、以下に記載されています。
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 | |
+------+---------------------------------------+--------------+
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、パトリックFalstrom、ラルフDroms、テッドハーディー、ジョンピーターソン、ロバート・スパークス、ナディーン・アボット、およびMykyta Yevstifeyevに感謝したいと思います。さらに、著者は、垂直測地系の教育のためのグレッグTroxelだけでなく、カール・リードに感謝したいと思います。解決のための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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年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.、BCP 43、RFC 2939、2000年9月 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、エド。、およびW. Arbaugh、エド。、 "DHCPメッセージの認証"、RFC 3118、2001年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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、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]全米画像とマッピング庁、 "国防総省（DOD）世界測地系1984（WGS 84）、第3版"、NIMA TR8350.2、2000年1月、<https://www1.nga.mil/PRODUCTSSERVICES / GEODESYGEOPHYSICS / WORLDGEODETICSYSTEM /ページ/ 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.
[伝える]ポーク、J.、ローゼン、B.、およびJ.ピーターソン、「セッション開始プロトコルのための場所搬送」、進歩、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]トムソン、M.とC.リード、バージョン、候補OpenGISの実装仕様06から142、「GMLは、インターネットエンジニアリングタスクフォース（IETF）によって使用するためにPIDF-LO形状アプリケーションスキーマ3.1.1」：0.0.9、 2006年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 USA、2008年11月-3700 MHz動作。
[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技術情報文書モデル立法上の<www.nena.org>、マルチライン電話システム用の911を強化。
[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.、コックス、S.、デイジー、P.、湖、R.、およびA.ホワイトサイド、 "地理マークアップ言語（GML）3.1.1"、OGC 03-105r1 7月2003。
[OGP.Geodesy] International Association of Oil & Gas Producers (OGP) Geodesy Resources, Geomatics Committee, <http://info.ogp.org.uk/geodesy/>.
石油・ガス生産の[OGP.Geodesy]国際交流協会（OGP）測地資源、空間情報科学委員会、<http://info.ogp.org.uk/geodesy/>。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、2001年1月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、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.、マリガン、D.、モリス、J.、およびJ.ピーターソン、 "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]ポーク、J.、Schnizlein、J.、およびM. Linsner、 "座標ベースのロケーションの設定については、動的ホスト構成プロトコル・オプション"、RFC 3825、2004年7月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinneと、H.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]トムソン、M.及びJ.ウィンター、RFC 5139、2008年2月 "プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）のための改訂シビックロケーションフォーマット"。
[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]ウィンターボトム、J.、トムソン、M.、およびH. Tschofenig、 "GEOPRIVプレゼンス情報データフォーマット場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項"、RFC 5491、2009年3月。
Appendix A. GML Mapping
付録A. GMLマッピング
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）を使用します。それ以外の場合は、2次元の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（フロア）である場合、この値は測地オブジェクトと一緒に提示されている市民のアドレスオブジェクト[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.
この付録では、測地位置のDHCPフォーマットで符号化位置の値はGMLで発現させることができる方法について説明します。マッピングは、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にマッピングすることができます。
A.1. GML Templates
A.1。 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):
高度をメートル（Aタイプ1）に設けられ、基準値は、WGS84（値1）である場合、適切なGML形状は、以下に説明するように$値$は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：プリズムsrsNameは= "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" のxmlns：GML = "のhttp：// WWW。 opengis.net/gml "> <GS：ベース> <GML：ポリゴン> <GML：外装> <GML：LinearRing> <GML：POSLIST> $ lowLatitude $ $ $ $ lowLongitude lowAltitude $ $ $ $ lowLatitude highLongitude $ $ $ lowAltitude $高緯度$ $ highLongitude $ $ lowAltitude $ $高緯度$ $ lowLongitude $ $ lowAltitude $ $ lowLatitude $ $ lowLongitude $ $ lowAltitude $ </ GML：POSLIST> </ GML：LinearRing> </ GML：外装> </ GML：ポリゴン> </ GS：ベース> <GS：高さUOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> $ highAltitude - lowAltitude $ </ GS：身長> </ GS：プリズム>
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：ポリゴンsrsName = "$ 2D-CRS-URN $" のxmlns：GML = "http://www.opengis.net/gml" >> <GML：外装> <GML：LinearRing> <GML：POSLIST> $ lowLatitude $ $ lowLongitude $ $ lowLatitude $ $ highLongitude $ $高緯度$ $ highLongitude $ $高緯度$ $ lowLongitude $ $ lowLatitude $ $ lowLongitude $ </ GML：POSLIST> </ GML：LinearRing> </ GML：外装> </ GML ：ポリゴン>
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 "は：OGC：DEF：CRS：EPSG :: 4326 URN" です。データは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を使用します。それ以外の場合は、2次元のCRSを使用しています。
<gml:Point srsName="$CRS-URN$" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos> </gml:Point>
<GML：ポイントsrsName = "$ CRS-URN $" のxmlns：GML = "http://www.opengis.net/gml"> <GML：POS> $緯度経度$ $ $ $ [高度] $ </ GML ：POS> </ GML：ポイント>
A.1.1. Finding Low and High Values Using Uncertainty Fields
A.1.1。不確実性フィールドを使用してLowとHigh値を求めます
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は、解像度フィールドは、値の多くのビット情報を含むかを示す、（ラレス、LORES、AltRes）が使用されます。示された値を越えるビットはゼロまたは1のいずれかであり得ます。
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).
以下の2つのセクションでは、上記テンプレートで（例えば、$ lowLatitude $、$ highAltitude $）緯度、経度、及び高度の境界を計算する方法について説明します。最初のセクションは、第二のセクションは、「不確定符号化」（DHCPv6のGeoLocオプション63とのDHCPv4 GeoLocオプション144）に対処しながら、これらの境界は、「解像度符号化」（DHCPv4のGeoConfオプション123）で計算される方法を記載しています。
A.1.1.1. Resolution Encoding
A.1.1.1。分解能エンコーディング
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).
緯度/経度及び解像度（ラレス、LORES）の符号化された値は、34ビットの符号なし整数として扱われている場合、以下を使用することができる（ここで、「>>」は、ビットごとの右シフトである「＆」 "、ビット単位でAND 〜」ビット否定され、そして 『|』）ビットごとのORです。
mask = 0x3ffffffff >> resolution lowvalue = value & ~mask highvalue = value | mask + 1
= 0x3ffffffff >>解像度lowvalue =値＆〜マスクhighvalueの=値をマスク|マスク+ 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).
これらの値が決定されると（画分の25ビット固定小数点表現であるので）、対応する浮動小数点数は、2 ^ 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
スケール= 2 ^（9 - 解像度）lowvalue =フロア（値/スケール）*スケールhighvalueの= lowvalue +スケール
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）があります。
A.1.1.2. Uncertainty Encoding
A.1.1.2。不確実性のエンコーディング
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
距離= 2 ^（8 - 不確実性）lowvalue =値 - 距離highvalueの=値+距離
Altitude uncertainty (AltUnc in version 1) uses the same process with different constants:
高度の不確実性（バージョン1でAltUnc）は、異なる定数と同じプロセスを使用します。
distance = 2 ^ (21 - uncertainty) lowvalue = value - distance
距離= 2 ^（21 - 不確かさ）lowvalue =値 - 距離
Appendix B. Calculations of Resolution
決議の付録B.計算
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).
2つの異なる位置のために以下の実施例は、（DHCPv4のGeoConfオプション123で使用される）緯度、経度、及び高度のための解像度の値を算出することができる方法を示します。両方の例では、地理的位置の値は、WGS84マップのデータを使用して、マップに由来しました。従って、これらの実施例において、データムフィールド= 1（00000001、または0x01の）値を有するであろう。
B.1. Location Configuration Information of "White House" (Example 1)
B.1。ロケーションの設定「ホワイトハウス」の情報（例1）
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.
ワシントンD.C.（1600ペンシルバニアアベニューNW、ワシントンD.C. 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]これは、その地理的位置を生じる21のラレス値および20のLORES値が満たすことができ緯度38.8984375ノース経度-77.0375977に38.8988616北と経度を-77.0371094緯度することです。これは、NENAによって要求された7000平方フィートに非常に近い75フィートまたは6669平方フィートで約89フィートの面積、です。この例では、サービス・プロバイダは、緊急サービスを呼び出すときに、デバイスは、この特定の位置についての解像度のこの最小量と位置設定情報を送信することを強制することができました。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In hexadecimal, this is 7B10484D CB986347 65ED42C4 1440000F 0001.
進数では、これは7B10484D CB986347 65ED42C4 1440000F 0001です。
B.1.1. Decoding Location Configuration Information with Resolution
B.1.1。解像度とデコードの場所の設定情報
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.
このオプションを復号する解像度の18ビット分解能の17ビット分解能の15及び17ビットの値を持つメートルの高度タイプで-77.0366000の経度、バージョン0（（7つの小数点へ）38.897647の緯度を与えます解像度）、および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メートルの範囲内の値を可能にします。
B.1.2. GML Representation of Decoded Location Configuration Information
B.1.2。デコードされたロケーションの設定情報のGML表現
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：ポイントsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GML = "http://www.opengis.net/gml"> <GML：POS> 38.897647 -77.0366 15 </ GML ：POS> </ GML：ポイント>
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の：プリズムsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" のxmlns：GML =「のhttp：// WWW。 opengis.net/gml「> <GS：ベース> <GML：ポリゴン> <GML：外装> <GML：リニアリング> <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：リニアリング> </ GML：外装> </ GML：ポリゴン> </ GS：ベース> <GS：高未反応=「URN：OGC：DEF：未反応：EPSG :: 9001「> 32 </のGS：高さ> </ GS：プリズム>
B.2. Location Configuration Information of "Sears Tower" (Example 2)
B.2。 「シアーズ・タワー」（例2）のロケーションの設定情報
Postal Address: Sears Tower 103rd Floor 233 S. Wacker Dr. Chicago, IL 60606
住所：シアーズタワー第103階233 S.ワッカー博士はシカゴ、IL 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
2の補数、34ビットの固定小数点を使用して、2の補数、34ビットの固定小数点を使用41.87884度ノース（又は41.87884度）、画分の緯度= 0x053c1f751、緯度= 0001010011110000011111011101010001経度87.63602度ウエスト（又は-87.63602度）の25ビットを緯度、画分の25ビット経度= 0xf50ba5b97、経度= 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
他= 30、0x1Eを、011110 ATYPE = 2、0x02の、000010高度= 103 0x00006700、000000000000000110011100000000
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.).
緯度と経度の精度のために、私たちに利用可能な最良の情報がシアーズタワーのすべてのための単一の地理LOCを示す一般的なマッピングサービスによって供給されました。したがって、我々は、値18（0x12にまたは010010）として値18（0x12にまたは010010）とLORESとしてラレスを表示しようとしています。これは41.8789062を緯度41.8769531緯度と-87.6367188度から-87.6347657度経度まで延びジオロケーションエリアを記述するであろう。これは、約373412平方フィートの面積である（713.3フィートX 523.5フィート）。
Appendix C. Calculations of Uncertainty
不確実性の付録C.計算
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.
次の例では、緯度、経度、及び高度（LatUnc、LongUnc、及びAltUncは、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オプションをデコードする例を説明します。テキスト結果はPIDF-LO [RFC4119]に含めるのに適した、GML [OGC-GML3.1.1]形式で表現されています。
These examples all assume a datum of WGS84 (datum = 1) and an Altitude Type of meters (AType = 1).
これらの例のすべては、WGS84の基準（= 1基準）とメートルの高度タイプ（ATYPE = 1）と仮定する。
C.1.1. Encoding a Location into DHCP Geodetic Form
C.1.1。 DHCP測地フォームに場所をコードします
This example draws a rough polygon around the Sydney Opera House. This polygon consists of the following six points:
この例では、シドニーオペラハウスの周りのラフなポリゴンを描画します。この多角形は、以下の6点で構成されています。
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 151.215906 S E 33.856299 151.215343 S E 33.856326 151.214731 S E 33.857533 151.214495 S E 33.857720 151.214613 S E 33.857369 151.215375 S 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.8570095、151.2152005）を見つけることによって選択されます。これは（1110111100010010010011011000001101、0100101110011011100010111011000011）バイナリ、または（それぞれにパディングをリードの余分な2ビットの）16進数で（3BC49360D、12E6E2EC3）として符号化されます。高度は、（バイナリ）000000000000000010000110110011又は000021B3（16進数）である33.7メートルに設定されています。
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.
この式の結果はバイナリで001111としてエンコードされ15、です。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の形態は、コード及びオプション長さ部分が異なります。
C.1.2. Decoding a Location from DHCP Geodetic Form
C.1.2。 DHCP測地フォームから場所をデコード
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.
1110111100010010010011011000001101の緯度値は-33.8570095003（10小数点以下）の値にデコードします。 0100101110011011100010111011000011の経度値は151.2152005136にデコードします。
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、次に34の電力（総ビット数）に2を引く（すなわち、数は2の補数負です）。
2. Divide the result by 2 to the power of 25 (the number of fractional bits) to determine the final value.
2.最終的な値を決定するために、25の電源（小数ビットの数）に2によって結果を割り。
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).
緯度と経度の不確定性は、セクション2.3.2からの式を用いて0.0009765625の不確実性値を与える、両方とも18です。したがって、デコードされた緯度は-33.8570095003 +/- 0.0009765625（又は-33.8579860628から-33.8560329378の範囲）であり、デコードされた経度は151.2152005136 +/- 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).
000000000000000010000110110011の符号化された高度は33.69921875にデコードします。 15の符号化された不確実性は64の値を与えます。従って、最終的な不確実性は33.69921875 +/- 64（又は-30.30078125から97.69921875の範囲）です。
C.1.2.1. GML Representation of Decoded Locations
C.1.2.1。デコードされた場所のGML表現
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：ポイントsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GML = "http://www.opengis.net/gml"> <GML：POS> -33.8570095003 151.2152005136 33.69921875 </ GML ：POS> </ GML：ポイント>
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の：プリズムsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" のxmlns：GML =「のhttp：// WWW。 opengis.net/gml「> <GS：ベース> <GML：ポリゴン> <GML：外装> <GML：リニアリング> <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：リニアリング> </ GML：外装> </ GML：ポリゴン> </ GS：ベース> <GS：高未反応=「URN：OGC：DEF：未反応：EPSG :: 9001「> 128 </のGS：高さ> </ GS：プリズム>
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】ポリゴンの頂点間の距離を短くすることをお勧めします。不確実性は1度（9以上の符号化された値）未満である場合、このようなGML表現のみ適切です。
Appendix D. Changes from
付録D.変更から
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.
かつてのセクション1.2および1.3 oを削除されました。セクション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.
版、RES、およびデータム：O旧データムフィールドは三つのフィールドに分割されました。これらのフィールドは、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.
付録Aに以前材料が更新され、短縮および付録Bに移動されているされているoを
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東ブッシュ大統領ターンパイクリチャードソン、TX 75082 USA
EMail: jmpolk@cisco.com
メールアドレス：jmpolk@cisco.com
Marc Linsner Cisco Systems Marco Island, FL 34145 USA
マルク・Linsnerシスコシステムズマルコアイランド、FL 34145 USA
EMail: marc.linsner@cisco.com
メールアドレス：marc.linsner@cisco.com
Martin Thomson Andrew Corporation PO Box U40 Wollongong University Campus, NSW 2500 AU
マーティン・トムソンアンドリュー・コーポレーション私書箱U40ウーロンゴン大学キャンパス、NSW 2500 AU
EMail: martin.thomson@andrew.com
メールアドレス：martin.thomson@andrew.com
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナードAboba（編集者）マイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bernard_aboba@hotmail.com
メールアドレス：bernard_aboba@hotmail.com