[要約] RFC 6225は、DHCPオプションを使用して座標ベースの位置設定情報を提供するための仕様です。このRFCの目的は、ネットワークデバイスの位置情報を効果的に配布するための標準化を提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
デバイスの位置は、地理空間（または測地）座標の観点から、または市民の住所として表すことができます。さまざまなアプリケーションが、1つの形式の位置情報により適している場合があります。したがって、測地形態と市民の両方の形式を同時に使用できます。
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クライアントはその場所を取得できます。たとえば、有線イーサネットホストは、これらのオプションを場所の決定に使用する場合があります。この場合、位置情報は、RFC 3046 [RFC3046]で定義された（サブオプション1として）定義された回路IDリレーエージェント情報オプション（RAIO）を使用して、DHCPサーバーによるWireMapから導き出すことができます。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サーバーがホストの位置決定を実行するために使用できる1つの方法を提供します。現在、リレーエージェントサブオプションには、ワイヤレスホストのデバイスレベルの位置決定に必要なデータセットは含まれていません。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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）、経度（ローア）、および高度（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.
不確実性は通常、ターゲットが配置されている領域として表されます。このドキュメントでは、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には、場所の各寸法の解像度パラメーターが含まれています。この解像度パラメーターはすべての次元に等しく適用する必要はないため、3つの位置要素のそれぞれに解像度値が含まれています。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]は、緊急コール内の場所と関連する不確実性を伝えるために使用されるため、DHCPV4およびDHCPV66に含まれる情報を変換するためにメカニズムが必要です。PIDF-LOへのオプション。このドキュメントでは、次の変換について説明します。
o DHCPv4 GeoConf Option 123 to PIDF-LO
o dhcpv4 geoconf option 123からpidf-lo
o DHCPv4 GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 to PIDF-LO
o dhcpv4 geolocオプション144およびdhcpv6 geolocオプション63からpidf-lo
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 field = 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 field = 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.
Atype：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 field = 1の場合、このフィールドは高度の不確実性を表します。このフィールドの内容は、Verフィールドの他の値に対して定義されていません。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：セクション2.4で説明されているAtypeフィールドで定義された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：Verフィールドは2ビットで、4つの潜在的なバージョンを提供します。この仕様では、バージョン1の動作を定義します。VERフィールドは、使用中のバージョンに関係なく、オプションの先頭から常に同じオフセットに配置されます。この仕様を実装する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.
ローア：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.
Atype：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で説明されているAtypeフィールドで定義された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 field = 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 field = 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.
Atype：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 field = 1の場合、このフィールドは高度の不確実性を表します。このフィールドの内容は、Verフィールドの他の値に対して定義されていません。
Altitude: A 30-bit value defined by the AType field, described in Section 2.4.
高度：セクション2.4で説明されているAtypeフィールドで定義された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：Verフィールドは2ビットで、4つの潜在的なバージョンを提供します。この仕様では、バージョン1の動作を定義します。VERフィールドは、使用中のバージョンに関係なく、オプションの先頭から常に同じオフセットに配置されます。
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の送信をサポートする必要があり、Responseの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サーバーは、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.
このドキュメントで定義されている座標参照システム（Datum値1-3）内で、-180〜180 10進数の範囲外の経度値または-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の例は、解像度フィールドの値が少ないと、デバイスが配置されている領域が増加することを示しています。ラレスフィールドの2の値は、グローブの1/6以下の精度を示しています（付録Bの最初の例を参照）。ラレス場の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値は有効と見なされる必要がある高次の経度ビットの数をコードします。この制限の右側に入力されたビットは、有効であると見なされる必要はなく、意図的に間違っているか、送信者によってゼロになっている可能性があります。ロアフィールドの2の値は、グローブの1/6以下の精度を示しています（付録Bの最初の例を参照）。ロアフィールドの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およびstengunc）は、それぞれの緯度と経度の値のそれぞれの不確実性の量を定量化します。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:
不確実性の量は、次の式に示されているように、エンコードされた値を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 ) )
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).
高度値の解釈方法は、高度タイプ（ATYPE）値と選択したデータムによって異なります。このドキュメントでは、3つの高度タイプの値が定義されています：不明（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ビット、固定点、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:
より大きな値は、次のような階から遠く離れた床を表しています。
- if positive, the floor value is farther above the ground floor.
- 正である場合、床値は1階から遠くにあります。
- if negative, the floor value is farther below the ground floor.
- 負の場合、床値は1階の下にあります。
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）の場合、0.0のaltres値は未知の高度を示します。最も正確な高度は、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.
Atype = 2（床）の場合、床が不明であることを示すために床値がDHCP応答に含まれている場合、またはAtype = 0の場合、Altresフィールドは最大精度に設定する必要があります。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 )
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 ) )
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]の定義に基づいて、このドキュメントでは3つのデータムが定義されています。
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は、4269のEPSG/OGPコード、またはurn "urn：ogc：def：crs：epsg :: 4269"によって識別されます。NAVD88は、5703のEPSG/ OGPコード、または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は、4269のEPSG/OGPコード、または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クライアントがこのオプションを「パラメーターリクエストリスト」に含めた場合にのみ、LCIオプションをDHCPサーバーによって返す必要があります（[RFC2131]のセクション3.5、[RFC2132]のセクション9.8）。
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]で定義されているDHCP認証と「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]:
このドキュメントでは、DHCPV6 GeoLOCオプション（セクション2.1を参照）を定義します。これは、[RFC3315]ごとに63のDHCPV6オプションコードが割り当てられています。
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.
このドキュメントでは、DHCP4オプションスペースから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]:
このドキュメントでは、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は、以下のガイドラインに従って、Datumレジストリを作成し、維持しています。
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.
著者は、ランドール・ゲレンズ、パトリック・ファルストロム、ラルフ・ドロム、テッド・ハーディ、ジョン・ピーターソン、ロバート・スパークス、ナディーン・アボット、マイキータ・イェフスタイエフ、この文書に関する建設的なコメントに感謝します。さらに、著者は、Carl Reedだけでなく、垂直データムの教育についてGreg Troxelに感謝したいと思います。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。、「動的ホスト構成プロトコル」、RFC 2131、1997年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 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。、「新しい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メッセージの認証」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、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/pages/default.aspx> and <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.
[Convey] 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。and C. Reed、「GML 3.1.1 Internet Engineering Task Force（IETF）が使用するPIDF-LO形状アプリケーションスキーマ」、候補OpenGIS実装仕様06-142、バージョン：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-3700 MHz Operation、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] National Emergency Number Association（Nena）、Nena Model Legislationに関する技術情報文書マルチライン電話システムの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、「Geography Markup Language（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）Geodesy Resources、Geomatics Committee、<http://info.ogp.org.uk/geodesy/>。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、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] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、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 3825、2004年7月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、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。、「Dynamic Host Configuration Protocol（DHCPV4およびDHCPV6）CIVICアドレス構成情報のオプション」、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 5491、2009年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の解釈が使用されているかどうかに関係なく当てはまります。ポイントに高度が含まれている場合、3次元座標参照システム（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：Polygon」形状を使用して長方形として記述されます。高度が利用可能な場合、3次元CRSが使用されます。それ以外の場合、2次元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）の場合、3次元座標をカバーする利用可能なCRS URNはありません。必然的に、これらのデータムに記載されている場所は、2次元の形状のみで表すことができます。つまり、2次元ポイントまたはポリゴンのいずれかです。
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にマッピングできます。
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):
高度がメートル（Atype 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>
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>
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-ur」は、データム値によって定義されます。データムがwgs84（値1）の場合、2d-crs-urは「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）、高度が指定されている場合（値1）、高度が指定されている場合、WGS84 3次元CRSを備えたポリゴン形状が使用されます。この場合、上記の各ポイントの後に高度フィールドの値が追加され、SRSNAME属性は3次元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）が指定されていない場合、単純な点形状が使用されます。高度では、これは3次元CRSを使用します。それ以外の場合、2次元CRSを使用します。
<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の場合、解像度フィールドが使用されます（LARE、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 $）を計算する方法について説明します。最初のセクションでは、これらの境界が「解像度エンコード」（DHCPV4 GeoCONFオプション123）で計算される方法について説明し、2番目のセクションでは「不確実性エンコード」（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).
緯度/経度と解像度のエンコードされた値（LARE、LORES）が34ビットの符号なし整数として扱われる場合、以下を使用できます（「>>」は少し正しいシフトです」＆「ビットワイズであり、」〜 "はビットワイズ否定であり、" | "はビットワイズまたは）です。
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
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）は、異なる定数で同じプロセスを使用します。高度エンコード（9ではなく）と合計（34ではなく）30ビットに22ビットがあります。
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
Altitude uncertainty (AltUnc in version 1) uses the same process with different constants:
高度の不確実性（バージョン1のAltunc）は、異なる定数で同じプロセスを使用します。
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).
2つの異なる場所の次の例は、緯度、経度、高度の解像度値（DHCPV4 GeoCONFオプション123で使用）を計算する方法を示しています。どちらの例でも、GGS84 MAP Datumを使用して地理ロケーション値はマップから導出されました。したがって、これらの例では、データムフィールドには値= 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.
ワシントンD.C.のホワイトハウスの敷地（1600ペンシルベニアアベニューNW、ワシントンDC 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.
この例では、National Emergency Number Association（Nena）モデル法[Nena]を介した北米の緊急対応者の要件は、21のLares値と20のLores値で満たすことができます。これにより、ジオロケーションが得られます。緯度38.8984375北から緯度38.8988616北、経度-77.0371094から経度-77.0375977です。これは、約89フィートx 75フィートまたは6669平方フィートの面積で、ネナが要求した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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In hexadecimal, this is 7B10484D CB986347 65ED42C4 1440000F 0001.
16進数では、これは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.
このオプションを解読すると、18ビットの解像度を持つ38.897647（7桁まで）の緯度、17ビットの解像度の-77.0366000の経度、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は、前の例で3次元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>
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>
Postal Address: Sears Tower 103rd Floor 233 S. Wacker Dr. Chicago, IL 60606
郵便住所：シアーズタワー103階233 S.ワッカー博士シカゴ、イリノイ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
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 = 30, 0x1e, 011110 AType = 2, 0x02, 000010 Altitude = 103, 0x00006700, 000000000000000110011100000000
altres = 30、0x1e、011110 atype = 2、0x02、000010 altitude = 103、0x00006700、000000000000000000011001000000000000
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）と値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で使用されるLatunc、Longunc、およびAltunc）のどのように計算できるかを示しています。
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（datum = 1）のデータムとメートルの高度タイプ（atype = 1）を想定しています。
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 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.85369 s
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）を見つけることによって選択されます。これは、バイナリで（111011110010010011011000001101、010010111101111000111011000011）としてエンコードされています。高度は33.7メートル、000000000000000010000110110011（バイナリ）または000021B3（16進数）に設定されています。
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 ) )
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 ) )
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 ) )
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341. The DHCPv6 form only differs in the code and option length portion.
16進数では、これは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.
11101111110010010010011011000001101の緯度値は、-33.8570095003（10小数点まで）の値にデコードします。0100101111001101111010111011000011の経度値は、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. 最高のオーダービットが設定されている場合（つまり、数は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.2152005136 /-0.0009510142511.214251.214251.214251.21411.2142551625162516251625162516256256256256256251625625625625625625625625625625625625623
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).
0000000000000010000110110011のエンコードされた高度は、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は、前の例で3次元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>
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>
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の3つのフィールドに分割されています。これらのフィールドは、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 USA
EMail: jmpolk@cisco.com
Marc Linsner Cisco Systems Marco Island, FL 34145 USA
マークリンナーシスコシステムマルコアイランド、フロリダ州34145アメリカ
EMail: marc.linsner@cisco.com
Martin Thomson Andrew Corporation PO Box U40 Wollongong University Campus, NSW 2500 AU
Martin Thomson Andrew Corporation PO Box U40 Wollongong University Campus、NSW 2500 AU
EMail: martin.thomson@andrew.com
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ（編集者）Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: bernard_aboba@hotmail.com