[要約] RFC 7035は、相対位置表現の標準化を目的としており、位置情報の相対的な表現方法を定義しています。このRFCは、位置情報の一貫性と相互運用性を向上させることを目指しています。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 7035 Microsoft
Category: Standards Track B. Rosen
ISSN: 2070-1721 Neustar
D. Stanley
Aruba Networks
G. Bajko
Nokia
A. Thomson
Lookingglass
October 2013
Relative Location Representation
相対位置表現
Abstract
概要
This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.
このドキュメントは、参照ポイントに関連して定義される位置情報の表現のための存在情報データ形式位置オブジェクト（PIDF-LO）（RFC 4119）の拡張を定義します。基準点は、測地または都市の位置として表すことができ、相対オフセットはいくつかの形状の1つになります。代替のバイナリ表現について説明します。
Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.
オプションで、2次ドキュメント（マップイメージなど）への参照を、マップ座標系と参照/オフセット座標系との関係とともに含めることができ、参照ポイントと相対オフセットでマップを表示できます。 。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7035.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7035で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Overview ........................................................4
4. Relative Location ...............................................7
4.1. Relative Coordinate System .................................8
4.2. Placement of XML Elements ..................................8
4.3. Binary Format ..............................................9
4.4. Distances and Angles .......................................9
4.5. Value Encoding ............................................10
4.6. Relative Location Restrictions ............................10
4.7. Baseline TLVs .............................................10
4.8. Reference TLVs ............................................10
4.9. Shapes ....................................................11
4.9.1. Point ..............................................11
4.9.2. Circle or Sphere Shape .............................12
4.9.3. Ellipse or Ellipsoid Shape .........................13
4.9.4. Polygon or Prism Shape .............................15
4.9.5. Arc-Band Shape .....................................18
4.10. Dynamic Location TLVs ....................................20
4.10.1. Orientation .......................................20
4.10.2. Speed .............................................20
4.10.3. Heading ...........................................20
4.11. Secondary Map Metadata ...................................21
4.11.1. Map URL ...........................................21
4.11.2. Map Coordinate Reference System ...................21
4.11.3. Map Example .......................................24
5. Examples .......................................................24
5.1. Civic PIDF with Polygon Offset ............................24
5.2. Geo PIDF with Circle Offset ...............................26
5.3. Civic TLV with Point Offset ...............................27
6. Schema Definition ..............................................28
7. Security Considerations ........................................30
8. IANA Considerations ............................................31
8.1. Relative Location Registry ................................31
8.2. URN Sub-Namespace Registration ............................33
8.3. XML Schema Registration ...................................33
8.4. Geopriv Identifiers Registry ..............................34
8.4.1. Registration of Two-Dimensional Relative
Coordinate Reference System URN ....................35
8.4.2. Registration of Three-Dimensional Relative
Coordinate Reference System URN ....................35
9. Acknowledgements ...............................................35
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................38
This document describes a format for the expression of relative location information.
このドキュメントでは、相対位置情報の表現形式について説明します。
A relative location is formed of a reference location plus a relative offset from that reference location. The reference location can be represented in either civic or geodetic form. The reference location can also have dynamic components such as velocity. The relative offset is specified in meters using a Cartesian coordinate system.
相対位置は、参照位置とその参照位置からの相対オフセットで構成されます。参照場所は、市民または測地の形式で表すことができます。参照位置には、速度などの動的コンポーネントも含めることができます。相対オフセットは、デカルト座標系を使用してメートル単位で指定されます。
In addition to the relative location, an optional URI can be provided to a document that contains a map, floor plan, or other spatially oriented information. Applications could use this information to display the relative location. Additional fields allow the map to be oriented and scaled correctly.
相対位置に加えて、オプションのURIを、マップ、フロアプラン、またはその他の空間指向の情報を含むドキュメントに提供できます。アプリケーションはこの情報を使用して、相対位置を表示できます。追加のフィールドを使用すると、マップの方向とサイズを正しく調整できます。
Two formats are included: an XML form that is intended for use in PIDF-LO [RFC4119] and a TLV format for use in other protocols such as those that already convey binary representation of location information defined in [RFC4776].
2つの形式が含まれています。PIDF-LO[RFC4119]での使用を目的としたXMLフォームと、[RFC4776]で定義された位置情報のバイナリ表現をすでに伝達するプロトコルなど、他のプロトコルで使用するTLV形式です。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document describes an extension to PIDF-LO [RFC4119] as updated by [RFC5139] and [RFC5491], to allow the expression of a location as an offset relative to a reference.
このドキュメントは、[RFC5139]と[RFC5491]によって更新されたPIDF-LO [RFC4119]の拡張機能について説明し、参照に対するオフセットとして位置を表現できるようにします。
Reference Location o \ \ Offset \ _\| x Relative Location
参照場所o \ \オフセット\ _ \ | x相対位置
This extension allows the creator of a location object to include two location values plus an offset. The two location values, named "baseline" and "reference", combine to form the origin of the offset.
この拡張機能により、場所オブジェクトの作成者は2つの場所の値とオフセットを含めることができます。 「ベースライン」と「リファレンス」という2つの位置の値を組み合わせて、オフセットの原点を形成します。
The final, relative location is described relative to this reference point.
最終的な相対位置は、この参照点を基準にして記述されます。
..--"""--..
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'
The baseline location is included outside of the <relative-location> element. The baseline location is visible to a client that does not understand relative location (i.e., it ignores the <relative-location> element).
ベースラインの場所は、<relative-location>要素の外側に含まれています。基準位置は、相対位置を理解していないクライアントに表示されます（つまり、<relative-location>要素を無視します）。
A client that does understand relative location will interpret the location within the relative element as a refinement of the baseline location. This document defines both a reference location, which serves as a refinement of the baseline location and the starting point, and an offset, which describes the location of the Target based on this starting point.
相対位置を理解しているクライアントは、相対要素内の位置をベースライン位置の詳細として解釈します。このドキュメントでは、ベースラインの位置と開始点の調整として機能する参照位置と、この開始点に基づいてターゲットの位置を説明するオフセットの両方を定義します。
Creators of location objects with relative location thus have a choice of how much information to put into the baseline location and how much to put into the reference location. For example, the baseline location value could be precise enough to specify a building that contains the relative location, and the reference location could specify a point within the building from which the offset is measured.
したがって、相対位置を持つ位置オブジェクトの作成者は、基準位置に配置する情報量と参照位置に配置する情報量を選択できます。たとえば、基準位置の値は、相対位置を含む建物を指定するのに十分正確である可能性があり、基準位置は、オフセットが測定される建物内のポイントを指定する可能性があります。
Location objects SHOULD NOT have all location information in the baseline location. Doing this would cause clients that do not understand relative location to incorrectly interpret the baseline location (i.e., the reference point) as the actual, precise location of the client. The baseline location is intended to carry a location that encompasses both the reference location and the relative location (i.e., the reference location plus offset).
ロケーションオブジェクトは、ベースラインロケーションにすべてのロケーション情報を持つべきではありません。これを行うと、相対位置を理解していないクライアントが、基準位置（つまり、基準点）をクライアントの実際の正確な位置として誤って解釈する可能性があります。基準位置は、基準位置と相対位置の両方を含む位置（つまり、基準位置とオフセット）を運ぶことを目的としています。
It is possible to provide a valid relative location with no information in the baseline. However, this provides recipients who do not understand relative location with no information. A baseline location SHOULD include sufficient information to encompass both the reference and relative locations while providing a baseline that is as accurate as possible.
ベースラインに情報がない有効な相対位置を提供することが可能です。ただし、これにより、相対的な場所を理解していない受信者に情報が提供されなくなります。基準位置には、基準位置と相対位置の両方を網羅するのに十分な情報を含め、可能な限り正確な基準を提供する必要があります（SHOULD）。
Both the baseline and the reference location are defined as either a geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If the baseline location was expressed as a geodetic location, the reference MUST be geodetic. If the baseline location was expressed as a civic address, the reference MUST be civic.
基準線と参照位置の両方が、測地位置[OGC.GeoShape]または市民の住所[RFC4776]として定義されています。ベースライン位置が測地位置として表現された場合、参照は測地でなければなりません。ベースラインの場所が市民の住所として表現された場合、参照は市民である必要があります。
Baseline and reference locations MAY also include dynamic location information [RFC5962].
ベースラインおよび参照場所には、動的な場所情報も含まれる場合があります[RFC5962]。
The relative location can be expressed using a point (2- or 3-dimensional) or a shape that includes uncertainty: circle, sphere, ellipse, ellipsoid, polygon, prism, or arc-band. Descriptions of these shapes can be found in [RFC5491].
相対位置は、点（2次元または3次元）または不確実性を含む形状（円、球、楕円、楕円、多角形、プリズム、または円弧）を使用して表すことができます。これらの形状の説明は[RFC5491]にあります。
Optionally, a reference to a 'map' document can be provided. The reference is a URI [RFC3986]. The document could be an image or dataset that represents a map, floor plan, or other form. The type of document the URI points to is described as a MIME media type [RFC2046]. Metadata in the relative location can include the location of the reference point in the map as well as an orientation (angle from North) and scale to align the document Coordinate Reference System (CRS) with the World Geodetic System 1984 (WGS84) [WGS84] CRS. The document is assumed to be usable by the application receiving the PIDF with the relative location to locate the reference point in the map. This document does not describe any mechanisms for displaying or manipulating the document other than providing the reference location, orientation, and scale.
オプションで、「マップ」ドキュメントへの参照を提供できます。参照はURI [RFC3986]です。ドキュメントは、マップ、フロアプラン、またはその他のフォームを表す画像またはデータセットにすることができます。 URIが指すドキュメントのタイプは、MIMEメディアタイプ[RFC2046]として記述されます。相対位置のメタデータには、マップ内の基準点の位置、および方向（北からの角度）と縮尺を含めることができ、文書の座標参照系（CRS）を世界測地系1984（WGS84）[WGS84]に合わせます。 CRS。ドキュメントは、マップ内の参照ポイントを特定するための相対位置を含むPIDFを受信するアプリケーションで使用できると想定されています。このドキュメントでは、参照の場所、方向、スケールを提供する以外に、ドキュメントを表示または操作するためのメカニズムについては説明していません。
As an example, consider a relative location expressed as a point, relative to a civic location:
例として、市民の位置を基準にして、点として表される相対位置を考えます。
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:relative@example.com">
<dm:device id="relative1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos>
</gml:Point>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
<rel:map>
<rel:url type="image/png">
http://example.com/location/map.png
</rel:url>
<rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale>
</rel:map>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
Relative location is a shape (e.g., point, circle, ellipse). The shape is defined with a CRS that has a datum defined as the reference (which appears as a civic address or geodetic location in the tuple) and the shape coordinates as meter offsets North/East of the datum measured in meters (with an optional Z offset relative to datum altitude). An optional angle allows the reference CRS be to rotated with respect to North.
相対位置は形状です（例：点、円、楕円）。形状は、参照として定義されたデータム（タプルでは都市の住所または測地の場所として表示されます）および形状座標をメートルで測定されたデータムの北/東（オプションのZデータム高度に対するオフセット）。オプションの角度により、基準CRSを北を基準に回転させることができます。
The relative coordinate reference system uses a coordinate system with two or three axes.
相対座標参照系は、2つまたは3つの軸を持つ座標系を使用します。
The baseline and reference locations are used to define a relative datum. The reference location defines the origin of the coordinate system. The centroid of the reference location is used when the reference location contains any uncertainty.
ベースラインと参照位置は、相対データムを定義するために使用されます。参照位置は、座標系の原点を定義します。基準位置の重心は、基準位置に不確実性が含まれている場合に使用されます。
The axes in this coordinate system are originally oriented based on the directions of East, North, and Up from the reference location: the first (x) axis increases to the East, the second (y) axis points North, and the optional third (z) axis points Up. All axes of the coordinate system use meters as a basic unit.
この座標系の軸は、最初は参照位置からの東、北、上方向に基づいて方向付けられています。最初の（x）軸は東に増加し、2番目（y）軸は北を指し、オプションの3番目（ z）軸は上向き。座標系のすべての軸は、メートルを基本単位として使用します。
Any coordinates in the relative shapes use the described Cartesian coordinate system. In the XML form, this uses a URN of "urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and "urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes. The binary form uses different shape type identifiers for 2D and 3D shapes.
相対形状の座標は、記述されたデカルト座標系を使用します。 XMLフォームでは、これは2次元形状の場合は「urn：ietf：params：geopriv：relative：2d」、3次元形状の場合は「urn：ietf：params：geopriv：relative：3d」のURNを使用します。バイナリ形式では、2Dおよび3D形状に異なる形状タイプ識別子を使用します。
Dynamic location information [RFC5962] in the baseline or reference location alters the relative coordinate system. The resulting Cartesian coordinate system axes are rotated so that the y axis is oriented along the direction described by the <orientation> element. The coordinate system also moves as described by the <speed> and <heading> elements.
ベースラインまたは参照位置の動的位置情報[RFC5962]は、相対座標系を変更します。結果のデカルト座標系の軸は、y軸が<orientation>要素によって記述された方向に沿って向けられるように回転されます。座標系も<speed>要素と<heading>要素で説明されているように移動します。
The single timestamp included in the tuple (or equivalent) element applies to all location elements, including all three components of a relative location: baseline, reference, and relative. This is particularly important when there are dynamic components to these items. A location generator is responsible for ensuring the consistency of these fields.
タプル（または同等の）要素に含まれる単一のタイムスタンプは、相対位置の3つのコンポーネント（ベースライン、参照、相対）をすべて含む、すべての位置要素に適用されます。これらのアイテムに動的コンポーネントがある場合、これは特に重要です。ロケーションジェネレータは、これらのフィールドの一貫性を保証する責任があります。
The baseline of the reference location is represented as <location-info> like a normal PIDF-LO. Relative location adds a new <relative-location> element to <location-info>. Within <relative-location>, <reference> and <offset> elements are described. Within <offset> are the shape elements described below. This document extends PIDF-LO as described in [RFC6848].
参照場所のベースラインは、通常のPIDF-LOと同様に<location-info>として表されます。相対ロケーションは、新しい<relative-location>要素を<location-info>に追加します。 <relative-location>内には、<reference>要素と<offset>要素が記述されています。 <offset>内には、以下で説明する形状要素があります。このドキュメントは、[RFC6848]で説明されているようにPIDF-LOを拡張します。
This document describes a way to encode the relative location in a binary TLV form for use in other protocols that use TLVs to represent location.
このドキュメントでは、TLVを使用して位置を表す他のプロトコルで使用するために、相対位置をバイナリTLV形式でエンコードする方法について説明します。
A type-length-value encoding is used.
type-length-valueエンコードが使用されます。
+------+------+------+------+------+------+------+
| Type |Length| Value ...
+------+------+------+------+------+------+------+
| T | N | Value ...
+------+------+------+------+------+------+------+
Figure 1: TLV Tuple Format
図1：TLVタプル形式
The Type field (T) is an 8-bit unsigned integer. The type codes used are registered in an IANA-managed "Relative Location Parameters" registry defined by this document and restricted to not include the values defined by the "Civic Address Types (CAtypes)" registry. This restriction permits a location reference and offset to be coded within the same object without type collisions.
Typeフィールド（T）は、8ビットの符号なし整数です。使用されるタイプコードは、このドキュメントで定義されているIANA管理の「相対位置パラメータ」レジストリに登録され、「Civic Address Types（CAtypes）」レジストリで定義されている値を含まないように制限されています。この制限により、位置の参照とオフセットを、タイプの衝突なしに同じオブジェクト内でコーディングできます。
The Length field (N) is defined as an 8-bit unsigned integer. This field can encode values from 0 to 255. The length field describes the number of bytes in the Value. Length does not count the bytes used for the Type or Length.
長さフィールド（N）は、8ビットの符号なし整数として定義されます。このフィールドは、0〜255の値をエンコードできます。長さフィールドは、値のバイト数を示します。長さは、タイプまたは長さに使用されるバイトをカウントしません。
The Value field is defined separately for each type.
値フィールドは、タイプごとに個別に定義されます。
Each element of the relative location has a unique TLV assignment. A relative location encoded in TLV form includes both baseline and reference location TLVs and relative location TLVs. The reference TLVs are followed by the relative offset and optional map TLVs described in this document.
相対位置の各要素には、一意のTLV割り当てがあります。 TLV形式でエンコードされた相対位置には、ベースラインと参照位置の両方のTLVと相対位置のTLVが含まれます。リファレンスTLVの後には、このドキュメントで説明されている相対オフセットとオプションのマップTLVが続きます。
All distance measures used in shapes are expressed in meters.
形状で使用されるすべての距離メジャーはメートルで表されます。
All orientation angles used in shapes are expressed in degrees. Orientation angles are measured from WGS84 Northing to Easting with zero at Northing. Orientation angles in the relative coordinate system start from the second coordinate axis (y or Northing) and increase toward the first axis (x or Easting).
形状で使用されるすべての方向角度は度で表されます。方位角は、WGS84北座標から東座標まで、北座標をゼロとして測定されます。相対座標系の方向角は、2番目の座標軸（yまたは北座標）から始まり、最初の軸（xまたは東座標）に向かって増加します。
The binary form uses single-precision floating-point values [IEEE.754] to represent coordinates, distance, and angle measures. Single-precision values are 32-bit values with a sign bit, 8 exponent bits, and 23 fractional bits. This uses the interchange format defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign, biased exponent and significand, with the most significant bit first.
バイナリ形式は、単精度浮動小数点値[IEEE.754]を使用して、座標、距離、および角度のメジャーを表します。単精度値は、符号ビット、8つの指数ビット、および23の小数ビットを持つ32ビット値です。これは、[IEEE.754]と[RFC1014]のセクション3.6で定義されている交換形式を使用しています。つまり、符号、バイアス付き指数、仮数で、最上位ビットが最初です。
Binary-encoded coordinate values are considered to be a single value without uncertainty. When encoding a value that cannot be exactly represented, the best approximation MUST be selected according to [Clinger1990].
バイナリエンコードされた座標値は、不確実性のない単一の値と見なされます。正確に表現できない値をエンコードする場合、[Clinger1990]に従って最良の近似を選択する必要があります。
More than one relative shape MUST NOT be included in either a PIDF-LO or TLV encoding of location for a given reference point.
特定の参照ポイントの場所のPIDF-LOまたはTLVエンコーディングに複数の相対形状を含めることはできません。
Any error in the reference point transfers to the location described by the relative location. Any errors arising from an implementation not supporting or understanding elements of the reference point directly increases the error (or uncertainty) in the resulting location.
基準点のエラーは、相対位置で示される位置に転送されます。参照ポイントの要素をサポートまたは理解していない実装から生じるエラーは、結果の場所のエラー（または不確実性）を直接増加させます。
Baseline locations are described using the formats defined in [RFC4776] or [RFC6225].
ベースラインの場所は、[RFC4776]または[RFC6225]で定義された形式を使用して記述されます。
When a reference is encoded in binary form, the baseline and reference locations are combined in a reference TLV. This TLV is identified with the code 111 and contains civic address TLVs (if the baseline was a civic) or geo TLVs (if the baseline was a geo).
参照がバイナリ形式でエンコードされると、ベースラインと参照の場所が参照TLVに結合されます。このTLVはコード111で識別され、市民の住所TLV（ベースラインが市民の場合）またはgeo TLV（ベースラインが地理の場合）を含みます。
+------+------+------+------+------+------+
| 111 |Length| Reference TLVs |
+------+------+------+------+------+------+
Figure 2: Reference TLV
図2：参照TLV
Shape data is used to represent regions of uncertainty for the reference and relative locations. Shape data in the reference location uses a WGS84 [WGS84] CRS. Shape data in the relative location uses a relative CRS.
形状データは、参照および相対位置の不確実な領域を表すために使用されます。参照場所の形状データは、WGS84 [WGS84] CRSを使用します。相対位置の形状データは相対CRSを使用します。
The XML form for shapes uses Geography Markup Language (GML) [OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference locations use the CRS URNs specified in [RFC5491]; relative locations use either a 2D CRS ("urn:ietf:params:geopriv:relative:2d") or a 3D ("urn:ietf:params:geopriv:relative:3d"), depending on the shape type.
シェイプのXMLフォームは、[RFC5491]のルールに準拠したGeography Markup Language（GML）[OGC.GML-3.1.1]を使用します。参照場所は、[RFC5491]で指定されたCRS URNを使用します。相対位置は、形状タイプに応じて、2D CRS（ "urn：ietf：params：geopriv：relative：2d"）または3D（ "urn：ietf：params：geopriv：relative：3d"）を使用します。
The binary form of each shape uses a different shape type for 2D and 3D shapes.
各形状のバイナリ形式は、2Dおよび3D形状に異なる形状タイプを使用します。
Nine shape type codes are defined.
9つの形状タイプコードが定義されています。
A point "shape" describes a single point with unknown uncertainty. It consists of a single set of coordinates.
点「形状」は、不確実性が不明な単一の点を表します。座標の単一のセットで構成されています。
In a two-dimensional CRS, the coordinate includes two values; in a three-dimensional CRS, the coordinate includes three values.
2次元のCRSでは、座標には2つの値が含まれます。 3次元CRSでは、座標には3つの値が含まれます。
A point is represented in GML using the following template:
ポイントは、次のテンプレートを使用してGMLで表されます。
<gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point>
Figure 3: GML Point Template
図3：GMLポイントテンプレート
Where "$CRS-URN$" is replaced by a "urn:ietf:params:geopriv:relative:2d" or "urn:ietf:params:geopriv:relative:3d" and "$Coordinate-3$" is omitted if the CRS is two-dimensional.
「$ CRS-URN $」は「urn：ietf：params：geopriv：relative：2d」または「urn：ietf：params：geopriv：relative：3d」に置き換えられ、「$ Coordinate-3 $」は省略されます。 CRSは2次元です。
The point shape is introduced by a TLV of 113 for a 2D point and 114 for a 3D point.
ポイント形状は、2Dポイントの場合は113、3Dポイントの場合は114のTLVによって導入されます。
+------+------+
| 113/4|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Figure 4: Point Encoding
図4：ポイントエンコーディング
A circle or sphere describes a single point with a single uncertainty value in meters.
円または球は、メートル単位の単一の不確実性値を持つ単一の点を表します。
In a two-dimensional CRS, the coordinate includes two values, and the resulting shape forms a circle. In a three-dimensional CRS, the coordinate includes three values, and the resulting shape forms a sphere.
2次元のCRSでは、座標には2つの値が含まれ、結果の形状は円を形成します。 3次元のCRSでは、座標には3つの値が含まれ、結果の形状は球を形成します。
A circle is represented in and converted from GML using the following template:
円は、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Circle>
Figure 5: GML Circle Template
図5：GMLサークルテンプレート
A sphere is represented in and converted from GML using the following template:
球は、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:Sphere xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$
</gs:radius>
</gs:Sphere>
Figure 6: GML Sphere Template
図6：GML Sphereテンプレート
A circular shape is introduced by a type code of 115. A spherical shape is introduced by a type code of 116.
タイプコード115によって円形が導入されました。タイプコード116によって球形が導入されました。
+------+------+
| 115/6|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
| Radius |
+------+------+------+------+
Figure 7: Circle or Sphere Encoding
図7：円または球のエンコーディング
An ellipse or ellipsoid describes a point with an elliptical or ellipsoidal uncertainty region.
楕円または楕円体は、楕円または楕円体の不確実性領域を持つ点を表します。
In a two-dimensional CRS, the coordinate includes two values plus a semi-major axis, a semi-minor axis, a semi-major axis orientation (clockwise from North). In a three-dimensional CRS, the coordinate includes three values, and in addition to the two-dimensional values, an altitude uncertainty (semi-vertical) is added.
2次元のCRSでは、座標には2つの値に加えて、準長軸、準短軸、準長軸方向（北から時計回り）が含まれます。 3次元のCRSでは、座標に3つの値が含まれ、2次元の値に加えて、高度の不確実性（準垂直）が追加されます。
An ellipse is represented in and converted from GML using the following template:
楕円は、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipse>
Figure 8: GML Ellipse Template
図8：GML楕円テンプレート
An ellipsoid is represented in and converted from GML using the following template:
楕円体は、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$
</gs:orientation>
</gs:Ellipsoid>
Figure 9: GML Ellipsoid Template
図9：GML楕円体テンプレート
An ellipse is introduced by a type code of 117, and an ellipsoid is introduced by a type code of 118.
楕円はタイプコード117で導入され、楕円はタイプコード118で導入されます。
+------+------+
| 117/8|Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+
Figure 10: Ellipse or Ellipsoid Encoding
図10：楕円または楕円体エンコード
A polygon or prism includes a number of points that describe the outer boundary of an uncertainty region. A prism also includes an altitude for each point and prism height.
ポリゴンまたはプリズムには、不確実性領域の外側の境界を表すいくつかの点が含まれています。プリズムには、各ポイントの高度とプリズムの高さも含まれます。
At least 3 points MUST be included in a polygon. In order to interoperate with existing systems, an encoding SHOULD include 15 or fewer points, unless the recipient is known to support larger numbers.
少なくとも3つのポイントがポリゴンに含まれている必要があります。既存のシステムと相互運用するために、受信者がより大きな数をサポートすることがわかっている場合を除き、エンコーディングには15以下のポイントを含める必要があります（SHOULD）。
A polygon is represented in and converted from GML using the following template:
ポリゴンは、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$
$Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ...
...
$CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
Figure 11: GML Polygon Template
図11：GMLポリゴンテンプレート
Alternatively, a series of <pos> elements can be used in place of the single "posList". Each <pos> element contains two or three coordinate values.
または、単一の「posList」の代わりに一連の<pos>要素を使用できます。各<pos>要素には、2つまたは3つの座標値が含まれています。
Note that the first point is repeated at the end of the sequence of coordinates and no explicit count of the number of points is provided.
最初のポイントは座標のシーケンスの最後に繰り返され、ポイント数の明示的なカウントは提供されないことに注意してください。
A GML polygon that includes altitude cannot be represented perfectly in TLV form. When converting to the binary representation, a two-dimensional CRS is used, and altitude is removed from each coordinate.
標高を含むGMLポリゴンは、TLV形式で完全に表現することはできません。バイナリ表現に変換する場合、2次元のCRSが使用され、高度は各座標から削除されます。
A prism is represented in and converted from GML using the following template:
プリズムは、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-3$
$Coordinate2-1$ ... ...
...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-3$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-3$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$
</gs:height>
</gs:Prism>
Figure 12: GML Prism Template
図12：GMLプリズムテンプレート
Alternatively, a series of <pos> elements can be used in place of the single "posList". Each <pos> element contains three coordinate values.
または、単一の「posList」の代わりに一連の<pos>要素を使用できます。各<pos>要素には3つの座標値が含まれています。
A polygon containing 2D points uses a type code of 119. A polygon with 3D points uses a type code of 120. A prism uses a type code of 121. The number of points can be inferred from the length of the TLV.
2Dポイントを含むポリゴンはタイプコード119を使用します。3Dポイントを含むポリゴンはタイプコード120を使用します。プリズムはタイプコード121を使用します。ポイントの数はTLVの長さから推測できます。
+------+------+
|119-21|Length|
+------+------+------+------+
| (3D-only) Height |
+------+------+------+------+
| Coordinate1-1 |
+------+------+------+------+
| Coordinate1-2 |
+------+------+------+------+
| (3D-only) Coordinate1-3 |
+------+------+------+------+
| Coordinate2-1 |
+------+------+------+------+
...
+------+------+------+------+
| CoordinateN-1 |
+------+------+------+------+
| CoordinateN-2 |
+------+------+------+------+
| (3D-only) CoordinateN-3 |
+------+------+------+------+
Figure 13: Polygon or Prism Encoding
図13：ポリゴンまたはプリズムのエンコーディング
Note that unlike the polygon representation in GML, the first and last points are not the same point in the TLV representation. The duplicated point is removed from the binary form.
GMLのポリゴン表現とは異なり、最初と最後のポイントはTLV表現の同じポイントではないことに注意してください。複製されたポイントは、バイナリ形式から削除されます。
An arc-band describes a region constrained by a range of angles and distances from a predetermined point. This shape can only be provided for a two-dimensional CRS.
アークバンドは、所定の点からの角度と距離の範囲によって制約された領域を表します。この形状は、2次元のCRSに対してのみ提供できます。
Distance and angular measures are defined in meters and degrees, respectively. Both are encoded as single-precision floating-point values.
距離と角度のメジャーは、それぞれメートルと度で定義されます。どちらも単精度浮動小数点値としてエンコードされます。
An arc-band is represented in and converted from GML using the following template:
アークバンドは、次のテンプレートを使用してGMLで表され、GMLから変換されます。
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1$ $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Outer-Radius$
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$
</gs:openingAngle>
</gs:ArcBand>
Figure 14: GML Arc-Band Template
図14：GMLアークバンドテンプレート
An arc-band is introduced by a type code of 122.
アークバンドはタイプコード122によって導入されます。
+------+------+
| 122 |Length|
+------+------+------+------+
| Coordinate |
+------+------+------+------+
| Coordinate |
+------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+
Figure 15: Arc-Band Encoding
図15：アークバンドエンコーディング
Dynamic location elements use the definitions in [RFC5962].
動的ロケーション要素は、[RFC5962]の定義を使用します。
The orientation of the Target is described using one or two angles. Orientation uses a type code of 123.
ターゲットの方向は、1つまたは2つの角度を使用して記述されます。方向は123のタイプコードを使用します。
+------+------+
| 123 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Figure 16: Dynamic Orientation TLVs
図16：動的方向TLV
The speed of the Target is a scalar value in meters per second. Speed uses a type code of 124.
ターゲットの速度は、メートル/秒単位のスカラー値です。 Speedはタイプコード124を使用します。
+------+------+
| 124 |Length|
+------+------+------+------+
| Speed |
+------+------+------+------+
Figure 17: Dynamic Speed TLVs
図17：動的速度TLV
The heading, or direction of travel, is described using one or two angles. Heading uses a type code of 125.
進行方向または進行方向は、1つまたは2つの角度を使用して記述されます。見出しはタイプコード125を使用します。
+------+------+
| 125 |Length|
+------+------+------+------+
| Angle |
+------+------+------+------+
| (Optional) Angle |
+------+------+------+------+
Figure 18: Dynamic Heading TLVs
図18：動的見出しTLV
The optional "map" URL can be used to provide a user of relative location with a visual reference for the location information. This document does not describe how the recipient uses the map nor how it locates the reference or offset within the map. Maps can be simple images, vector files, 2D or 3D geospatial databases, or any other form of representation understood by both the sender and recipient.
オプションの「マップ」URLを使用して、相対位置のユーザーに位置情報の視覚的参照を提供できます。このドキュメントでは、受信者がマップを使用する方法や、マップ内の参照またはオフセットを見つける方法については説明していません。マップは、単純な画像、ベクターファイル、2Dまたは3D地理空間データベース、または送信者と受信者の両方が理解できるその他の形式の表現にすることができます。
In XML, the map is a <map> element defined within <relative-location> and contains the URL. The URL is encoded as a UTF-8-encoded string. An "http:" [RFC2616] or "https:" [RFC2818] URL MUST be used unless the entity creating the PIDF-LO is able to ensure that authorized recipients of this data are able to use other URI schemes. A "type" attribute MUST be present and specifies the kind of map the URL points to. Map types are specified as MIME media types as recorded in the IANA Media Types registry, for example, <map type="image/png"> https://www.example.com/floorplans/123South/floor-2</map>.
XMLでは、マップは<relative-location>内で定義された<map>要素であり、URLが含まれています。 URLは、UTF-8エンコードされた文字列としてエンコードされます。 「http：」[RFC2616]または「https：」[RFC2818] URLは、PIDF-LOを作成するエンティティがこのデータの承認された受信者が他のURIスキームを使用できることを保証できない限り、使用する必要があります。 「type」属性が存在する必要があり、URLが指すマップの種類を指定します。マップタイプは、IMAPメディアタイプレジストリに記録されているMIMEメディアタイプとして指定されます（例：<map type = "image / png"> https://www.example.com/floorplans/123South/floor-2</map）。 >。
In binary, the map type is a separate TLV from the map URL. The media type uses a type code of 126; the URL uses a type code of 127.
バイナリでは、マップタイプはマップURLとは別のTLVです。メディアタイプはタイプコード126を使用します。 URLはタイプコード127を使用します。
+------+------+------+------+------+------+------+
| 126 |Length| Map Media Type ...
+------+------+------+------+------+------+------+
| 127 |Length| Map Image URL ...
+------+------+------+------+------+------+------+
Figure 19: Map URL TLVs
図19：マップURL TLV
Note that the binary form restricts data to 255 octets. This restriction could be problematic for URLs in particular. Applications that use the XML form, but cannot guarantee that a binary form won't be used, are encouraged to limit the size of the URL to fit within this restriction.
バイナリ形式では、データが255オクテットに制限されることに注意してください。この制限は、特にURLで問題になる可能性があります。 XMLフォームを使用するが、バイナリフォームが使用されないことを保証できないアプリケーションでは、この制限内に収まるようにURLのサイズを制限することをお勧めします。
The CRS used by the map depends on the type of map. For example, a map described by a 3-D geometric model of the building may contain a complete CRS description in it. For some kinds of maps, typically described as images, the CRS used within the map must define the following: o The CRS origin
マップで使用されるCRSは、マップのタイプによって異なります。たとえば、建物の3D幾何モデルで記述されたマップには、完全なCRS記述が含まれている場合があります。一部の種類のマップ（通常は画像として説明されます）の場合、マップ内で使用されるCRSは以下を定義する必要があります。o CRSオリジン
o The CRS axes used and their orientation
o 使用されるCRS軸とその方向
o The unit of measure used
o 使用される測定単位
This document provides elements that allow for a mapping between the local coordinate reference system used for the relative location and the coordinate reference system used for the map where they are not the same.
このドキュメントでは、相対位置に使用されるローカル座標参照システムと、マップに使用される座標参照システムが同じでない場合に、それらのマッピングを可能にする要素を提供します。
This optional element identifies the coordinates of the reference point as it appears in the map. This value is measured in a map-type-dependent manner, using the coordinate system of the map.
このオプションの要素は、マップに表示される参照ポイントの座標を識別します。この値は、マップの座標系を使用して、マップタイプに依存する方法で測定されます。
For image maps, coordinates start from the upper left corner, and coordinates are first counted by column with positive values to the right; then, rows are counted with positive values toward the bottom of the image. For such an image, the first item is columns, the second rows, and any third value applies to any third dimension used in the image coordinate space.
イメージマップの場合、座標は左上隅から始まり、座標は最初に右の列に正の値でカウントされます。次に、行は画像の下部に向かって正の値でカウントされます。このような画像の場合、最初の項目は列、2番目の行であり、3番目の値は画像座標空間で使用される3番目の次元に適用されます。
The <offset> element contains 2 (or 3) coordinates similar to a GML <pos>. For example:
<offset>要素には、GML <pos>と同様の2（または3）座標が含まれています。例えば：
<offset> 2670.0 1124.0 1022.0</offset>
The map reference point uses a type code of 129.
マップ参照点は、タイプコード129を使用します。
+------+------+
| 129 |Length|
+------+------+------+------+
| Coordinate-1 |
+------+------+------+------+
| Coordinate-2 |
+------+------+------+------+
| (3D-only) Coordinate-3 |
+------+------+------+------+
Figure 20: Map Reference Point Coordinates TLV
図20：マップ参照点座標TLV
If omitted, a value containing all zeros is assumed. If the coordinates provided contain fewer values than are needed, the first value from the set is applied in place of any absent values. Thus, if a single value is provided, that value is used for Coordinate-2 and Coordinate-3 (if required). If two values are provided and three are required, the value of Coordinate-1 is used in place of Coordinate-3.
省略すると、すべてゼロを含む値と見なされます。提供された座標に必要な値よりも少ない値が含まれている場合は、セットの最初の値が、存在しない値の代わりに適用されます。したがって、単一の値が指定された場合、その値はCoordinate-2およびCoordinate-3（必要な場合）に使用されます。 2つの値が提供され、3つが必要な場合、Coordinate-3の代わりにCoordinate-1の値が使用されます。
The map orientation includes the orientation of the map direction in relation to the Earth. Map orientation is expressed relative to the orientation of the relative coordinate system. This means that map orientation with respect to WGS84 North is the sum of the orientation field and any orientation included in a dynamic portion of the reference location. Both values default to zero if no value is specified.
地図の向きには、地球に対する地図の向きも含まれます。マップの向きは、相対座標系の向きを基準にして表されます。これは、WGS84 Northに関するマップの方向が、方向フィールドと、基準位置の動的な部分に含まれる方向の合計であることを意味します。値が指定されていない場合、両方の値はデフォルトでゼロになります。
This type uses a single-precision floating-point value of degrees relative to North.
この型は、北を基準とした度数の単精度浮動小数点値を使用します。
In XML, the <orientation> element contains a single floating-point value, for example, <orientation>67.00</orientation>. In TLV form, map orientation uses the code 130:
XMLでは、<orientation>要素には、<orientation> 67.00 </ orientation>などの単一の浮動小数点値が含まれます。 TLV形式では、マップの向きはコード130を使用します。
+------+------+------+------+------+------+
| 130 |Length| Angle |
+------+------+------+------+------+------+
Figure 21: Map Orientation TLV
図21：マップ方向TLV
The optional map scale describes the relationship between the units of measure used in the map, relative to the meters unit used in the relative coordinate system.
オプションのマップスケールは、相対座標系で使用されるメートル単位を基準として、マップで使用される測定単位間の関係を表します。
This type uses a sequence of IEEE 754 [IEEE.754] single-precision floating-point values to represent scale as a sequence of numeric values. The units of these values are dependent on the type of map and could, for example, be pixels per meter for an image.
このタイプは、IEEE 754 [IEEE.754]単精度浮動小数点値のシーケンスを使用して、スケールを数値のシーケンスとして表します。これらの値の単位は、マップのタイプによって異なり、たとえば、画像の1メートルあたりのピクセル数にすることができます。
A scaling factor is provided for each axis in the coordinate system. For a two-dimensional coordinate system, two values are included to allow for different scaling along the x and y axes independently. For a three-dimensional coordinate system, three values are specified for the x, y, and z axes. Decoders can determine the number of scaling factors by examining the length field.
スケーリング係数は、座標系の各軸に提供されます。 2次元座標系の場合、x軸とy軸に沿って別々にスケーリングできるように2つの値が含まれています。 3次元座標系の場合、x、y、z軸に3つの値が指定されます。デコーダーは、長さフィールドを調べることにより、スケーリング係数の数を決定できます。
Alternatively, a single scaling value MAY be used to apply the same scaling factor to all coordinate components.
または、単一のスケーリング値を使用して、すべての座標コンポーネントに同じスケーリング係数を適用してもよい（MAY）。
Images that use a rows/columns coordinate system often use a left-handed coordinate system. A negative value for the y/rows axis scaling value can be used to account for any change in direction between the y axis used in the relative coordinate system and the rows axis of the image coordinate system.
行/列座標系を使用する画像は、多くの場合、左手座標系を使用します。 y /行軸のスケーリング値に負の値を使用すると、相対座標系で使用されるy軸と画像座標系の行軸の間の方向の変化を考慮することができます。
In XML, the <scale> element MAY contain a single scale value or MAY contain 2 (or 3) values in XML list form. In TLV form, scale uses a type code of 131. The length of the TLV determines how many scale values are present:
XMLでは、<scale>要素に単一のスケール値が含まれる場合と、XMLリスト形式で2つ（または3つ）の値が含まれる場合があります（MAY）。 TLV形式では、スケールはタイプコード131を使用します。TLVの長さは、存在するスケール値の数を決定します。
+------+------+------+------+------+------+
| 131 |Length| Scale(s) ...
+------+------+------+------+------+------+
Figure 22: Map Scale TLV
図22：マップスケールTLV
An example of expressing a map is:
マップを表現する例は次のとおりです。
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
Figure 23: Map Example
図23：マップの例
The examples in this section combine elements from [RFC3863], [RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape].
このセクションの例では、[RFC3863]、[RFC4119]、[RFC4479]、[RFC5139]、および[OGC.GeoShape]の要素を組み合わせています。
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<dm:device id="nesspc-1">
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO>
</ca:civicAddress>
<rel:relative-location>
<rel:reference>
<ca:civicAddress xml:lang="en-AU">
<ca:LMK>Front Door</ca:LMK>
<ca:BLD>A</ca:BLD>
<ca:FLR>I</ca:FLR>
<ca:ROOM>113</ca:ROOM>
</ca:civicAddress>
</rel:reference>
<rel:offset>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:exterior>
<gml:LinearRing>
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
<gml:pos>431.0 -733.0</gml:pos> <!--F-->
<gml:pos>431.0 -732.0</gml:pos> <!--E-->
<gml:pos>433.0 -731.0</gml:pos> <!--D-->
<gml:pos>434.0 -732.0</gml:pos> <!--C-->
<gml:pos>434.0 -733.0</gml:pos> <!--B-->
<gml:pos>433.0 -734.0</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</rel:offset>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>GPS</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:point2d@example.com">
<dm:device id="point2d">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0
</gs:radius>
</gs:Circle>
<rel:relative-location>
<rel:reference>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</rel:reference>
<rel:offset>
<gs:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gs:radius>
</gs:Circle>
</rel:offset>
<rel:map>
<rel:url type="image/png">
https://www.example.com/flrpln/123South/flr-2
</rel:url>
<rel:offset>2670.0 1124.0 1022.0</rel:offset>
<rel:orientation>67.00</rel:orientation>
<rel:scale>10 -10</rel:scale>
</rel:map>
</rel:relative-location>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
+--------+-------------------------------------------------+
| Type | Value |
+--------+-------------------------------------------------+
| 0 | en |
| | |
| 1 | IL |
| | |
| 3 | Chicago |
| | |
| 34 | Wacker |
| | |
| 18 | Drive |
| | |
| 19 | 3400 |
| | |
| 112 | Reference |
| | |
| 25 | Building A |
| | |
| 27 | Floor 6 |
| | |
| 26 | Suite 213 |
| | |
| 28 | Reception Area |
| | |
| 115 | 100 70 |
| | |
| 126 | image/png |
| | |
| 127 | http://maps.example.com/3400Wacker/A6 |
| | |
| 129 | 0.0 4120.0 |
| | |
| 130 | 113.0 |
| | |
| 131 | 10.6 |
+--------+-------------------------------------------------+
Note: The pattern value for "mimeType" has been folded onto multiple lines. Whitespace has been added to conform to comply with document formatting restrictions. Extra whitespace around the line endings MUST be removed before using this schema.
注：「mimeType」のパターン値は複数行に折り返されています。ドキュメントのフォーマット制限に準拠するために空白が追加されました。このスキーマを使用する前に、行末の余分な空白を削除する必要があります。
<?xml version="1.0"?>
<xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:relative">
Relative Location for PIDF-LO
</xs:appinfo>
<xs:documentation source="http://ietf.org/rfc/rfc7035.txt">
This schema defines a location representation that allows for
the description of locations that are relative to another.
An optional map reference is also defined.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="relative-location" type="rel:relativeType"/>
<xs:complexType name="relativeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="reference" type="rel:referenceType"/>
<xs:element name="offset" type="rel:offsetType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="referenceType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="offsetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="gml:_Geometry"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="map" type="rel:mapType"/>
<xs:complexType name="mapType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="url" type="rel:mapUrlType"/>
<xs:element name="offset" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="orientation" type="rel:doubleList"
minOccurs="0"/>
<xs:element name="scale" type="rel:doubleList"
minOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="mapUrlType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="type" type="rel:mimeType"
default="application/octet-stream"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="mimeType">
<xs:restriction base="xs:token">
<xs:pattern value="[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+
/[!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+([\t ]*;([\t ])*[!#$%&
'\*\+\-\.\dA-Z^_`a-z\|~]+=([!#$%&'\*\+\-\.\dA-Z^_`a-z\|~]+|
"([!#-\[\]-~]|[\t ]*|\\[\t !-~])*"))*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/>
</xs:simpleType>
</xs:schema>
This document describes a data format. To a large extent, security properties of this depend on how this data is used.
このドキュメントでは、データ形式について説明します。このセキュリティプロパティは、このデータの使用方法に大きく依存します。
Privacy for location data is typically important. Adding relative location may increase the precision of the location but does not otherwise alter its privacy considerations, which are discussed in [RFC4119].
場所データのプライバシーは通常重要です。相対位置を追加すると、位置の精度が向上する可能性がありますが、[RFC4119]で説明されているプライバシーに関する考慮事項は変更されません。
The map URL provided in a relative location could accidentally reveal information if a Location Recipient uses the URL to acquire the map. The coverage area of a map, or parameters of the URL itself, could provide information about the location of a Target. In combination with other information that could reveal the set of potential Targets that the Location Recipient has location information for, acquiring a map could leak significant information. In particular, it is important to note that the Target and Location Recipient are often the same entity.
相対位置で提供されたマップURLは、ロケーション受信者がURLを使用してマップを取得した場合、誤って情報を明らかにする可能性があります。マップのカバレッジエリア、またはURL自体のパラメーターは、ターゲットの場所に関する情報を提供できます。ロケーション受信者がロケーション情報を持っている潜在的なターゲットのセットを明らかにする可能性がある他の情報と組み合わせて、マップを取得すると重要な情報が漏洩する可能性があります。特に、ターゲットと場所の受信者が同じエンティティである場合が多いことに注意することが重要です。
Access to map URLs MUST be secured with TLS [RFC5246] (that is, restricting the map URL to be an https URI), unless the map URL cannot leak information about the Target's location. This restricts information about the map URL to the entity serving the map request. If the map URL conveys more information about a Target than a map server is authorized to receive, that URL MUST NOT be included in the PIDF-LO.
マップURLがターゲットの場所に関する情報をリークできない場合を除き、マップURLへのアクセスはTLS [RFC5246]で保護する必要があります（つまり、マップURLをhttps URIに制限します）。これにより、マップURLに関する情報が、マップリクエストを処理するエンティティに制限されます。マップURLが、マップサーバーが受信を許可されているよりも多くのターゲットに関する情報を伝達する場合、そのURLはPIDF-LOに含めてはなりません（MUST NOT）。
This document creates a new registry called "Relative Location Parameters". This shares a page, titled "Civic Address Types Registry" with the existing "Civic Address Types (CAtypes)" registry. As defined in [RFC5226], this new registry operates under "IETF Review" rules.
このドキュメントは、「Relative Location Parameters」と呼ばれる新しいレジストリを作成します。これは、「Civic Address Types Registry」というタイトルのページを既存の「Civic Address Types（CAtypes）」レジストリと共有します。 [RFC5226]で定義されているように、この新しいレジストリは「IETFレビュー」ルールの下で動作します。
The content of this registry includes:
このレジストリの内容は次のとおりです。
Relative Location Code (RLtype): Numeric identifier, assigned by IANA.
相対ロケーションコード（RLtype）：IANAによって割り当てられた数値識別子。
Brief description: Short description identifying the meaning of the element.
簡単な説明：要素の意味を識別する簡単な説明。
Reference to published specification: A stable reference to an RFC that describes the value in sufficient detail so that interoperability between independent implementations is possible.
公開された仕様への参照：独立した実装間の相互運用性が可能になるように十分詳細に値を説明するRFCへの安定した参照。
Values requested to be assigned into this registry MUST NOT conflict with values assigned in the "Civic Address Types (CAtypes)" registry or vice versa, unless the IANA Considerations section for the new value explicitly overrides this prohibition and the document defining the value describes how conflicting TLV codes will be interpreted by implementations. To ensure this, the CAtypes entries are explicitly reserved in the initial values table below. Those reserved entries can be changed, but only with caution, as explained here.
このレジストリへの割り当てを要求された値は、「Civic Address Types（CAtypes）」レジストリで割り当てられた値と競合してはなりません。その逆も同じです。ただし、新しい値のIANAの考慮事項セクションがこの禁止事項を明示的にオーバーライドし、値を定義するドキュメントで方法を説明している場合を除きます競合するTLVコードは、実装によって解釈されます。これを確実にするために、CAtypesエントリは、以下の初期値表で明示的に予約されています。これらの予約済みエントリは変更できますが、ここで説明するように、注意が必要です。
To make this clear for future users of the registry, the following note is added to the "Civic Address Types (CAtypes)" registry:
レジストリの将来のユーザーのためにこれを明確にするために、「Civic Address Types（CAtypes）」レジストリに次の注記が追加されています。
The registration of new values should be accompanied by a corresponding reservation in the Relative Location Parameters registry.
新しい値の登録には、Relative Location Parametersレジストリでの対応する予約が伴う必要があります。
Similarly, the "Relative Location Parameters" registry bears the note:
同様に、「Relative Location Parameters」レジストリには次の注意事項があります。
The registration of new values should be accompanied by a corresponding reservation in the Civic Address Types (CAtypes) registry.
新しい値の登録には、Civic Address Types（CAtypes）レジストリでの対応する予約が伴う必要があります。
The values defined are:
定義されている値は次のとおりです。
+--------+----------------------------------------+-----------+
| RLtype | description | Reference |
+--------+----------------------------------------+-----------+
| 0-40 | RESERVED by CAtypes registry | RFC 7035 &|
| 128 | | RFC 4776 |
+--------+----------------------------------------+-----------+
| 111 | relative location reference | RFC 7035 |
| 113 | relative location shape 2D point | RFC 7035 |
| 114 | relative location shape 3D point | RFC 7035 |
| 115 | relative location shape circular | RFC 7035 |
| 116 | relative location shape spherical | RFC 7035 |
| 117 | relative location shape elliptical | RFC 7035 |
| 118 | relative location shape ellipsoid | RFC 7035 |
| 119 | relative location shape 2D polygon | RFC 7035 |
| 120 | relative location shape 3D polygon | RFC 7035 |
| 121 | relative location shape prism | RFC 7035 |
| 122 | relative location shape arc-band | RFC 7035 |
| 123 | relative location dynamic orientation | RFC 7035 |
| 124 | relative location dynamic speed | RFC 7035 |
| 125 | relative location dynamic heading | RFC 7035 |
| 126 | relative location map type | RFC 7035 |
| 127 | relative location map URI | RFC 7035 |
| 129 | relative location map coordinates | RFC 7035 |
| 130 | relative location map angle | RFC 7035 |
| 131 | relative location map scale | RFC 7035 |
+--------+----------------------------------------+-----------+
This document registers a new XML namespace, as per the guidelines in [RFC3688].
このドキュメントは、[RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@skype.net）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location</title>
</head>
<body>
<h1>Format for representing relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7035.txt">
RFC 7035</a>.</p>
</body>
</html>
END
終わり
This section registers an XML schema as per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順に従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relative
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@skype.net）
Schema: The XML for this schema is found in Section 6 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション6にあります。
This section registers two URNs for use in identifying relative coordinate reference systems. These are added to a new "Geopriv Identifiers" registry according to the procedures in Section 4 of [RFC3553]. The "Geopriv Identifiers" registry is entered under the "Uniform Resource Name (URN) Namespace for IETF Use" category.
このセクションでは、相対座標参照系の識別に使用する2つのURNを登録します。これらは、[RFC3553]のセクション4の手順に従って、新しい「Geopriv Identifiers」レジストリに追加されます。 「Geopriv Identifiers」レジストリは、「IETF使用のためのUniform Resource Name（URN）名前空間」カテゴリの下に入力されます。
Registrations in this registry follow the "IETF Review" [RFC5226] policy.
このレジストリへの登録は、「IETFレビュー」[RFC5226]ポリシーに従います。
Registry name: Geopriv Identifiers
レジストリ名：Geopriv Identifiers
URN Prefix: urn:ietf:params:geopriv:
URNプレフィックス：urn：ietf：params：geopriv：
Specification: RFC 7035 (this document)
仕様：RFC 7035（このドキュメント）
Repository: http://www.iana.org/assignments/geopriv-identifiers
Index value: Values in this registry are URNs or URN prefixes that start with the prefix "urn:ietf:params:geopriv:". Each is registered independently.
インデックス値：このレジストリの値は、接頭辞「urn：ietf：params：geopriv：」で始まるURNまたはURN接頭辞です。それぞれが個別に登録されます。
Each registration in the "Geopriv Identifiers" registry requires the following information:
"Geopriv Identifiers"レジストリの各登録には、次の情報が必要です。
URN: The complete URN that is used or the prefix for that URN.
URN：使用される完全なURNまたはそのURNのプレフィックス。
Description: A summary description for the URN or URN prefix.
説明：URNまたはURNプレフィックスの概要説明。
Specification: A reference to a specification describing the URN or URN prefix.
仕様：URNまたはURN接頭辞を記述する仕様への参照。
Contact: Email for the person or groups making the registration.
連絡先：登録を行う人またはグループのメール。
Index value: As described in [RFC3553], URN prefixes that are registered include a description of how the URN is constructed. This is not applicable for specific URNs.
インデックス値：[RFC3553]で説明されているように、登録されているURNプレフィックスには、URNの構成方法の説明が含まれています。これは特定のURNには適用されません。
The "Geopriv Identifiers" registry has two initial registrations, included in the following sections.
「Geopriv Identifiers」レジストリには、次のセクションに含まれる2つの初期登録があります。
8.4.1. Registration of Two-Dimensional Relative Coordinate Reference System URN
8.4.1. Registration of Two-Dimensional Relative Coordinate Reference System URN
This section registers the "urn:ietf:params:geopriv:relative:2d" URN in the "Geopriv Identifiers" registry.
このセクションでは、「urn：ietf：params：geopriv：relative：2d」URNを「Geopriv Identifiers」レジストリに登録します。
URN: urn:ietf:params:geopriv:relative:2d
Description: A two-dimensional relative coordinate reference system
説明：2次元の相対座標参照系
Specification: RFC 7035 (this document)
仕様：RFC 7035（このドキュメント）
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@skype.net）
Index value: N/A
インデックス値：なし
8.4.2. Registration of Three-Dimensional Relative Coordinate Reference System URN
8.4.2. 三次元相対座標参照系URNの登録
This section registers the "urn:ietf:params:geopriv:relative:3d" URN in the "Geopriv Identifiers" registry.
このセクションでは、「urn：ietf：params：geopriv：relative：3d」URNを「Geopriv Identifiers」レジストリに登録します。
URN: urn:ietf:params:geopriv:relative:3d
Description: A three-dimensional relative coordinate reference system
説明：3次元の相対座標参照系
Specification: RFC 7035 (this document)
仕様：RFC 7035（このドキュメント）
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@skype.net）
Index value: N/A
インデックス値：なし
This document is the product of a design team on relative location. Besides the authors, this team included Marc Linsner, James Polk, and James Winterbottom.
このドキュメントは、相対位置に関する設計チームの製品です。著者の他に、このチームにはマークリンスナー、ジェームスポーク、ジェームズウィンターボトムが含まれていました。
[Clinger1990] Clinger, W., "How to Read Floating Point Numbers Accurately", Proceedings of Conference on Programming Language Design and Implementation, pp. 92-101, 1990.
[Clinger1990] Clinger、W.、「浮動小数点数を正確に読み取る方法」、プログラミング言語の設計と実装に関する会議議事録、pp。92-101、1990。
[IEEE.754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754-2008, August 2008.
[IEEE.754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754-2008, August 2008.
[OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OpenGIS 03-105r1, April 2004, <http://portal.opengeospatial.org/files/ ?artifact_id=4700>.
[OGC.GML-3.1.1] Cox、S.、Daisey、P.、Lake、R.、Portele、C。、およびA. Whiteside、「地理情報-Geography Markup Language（GML）」、OpenGIS 03-105r1 、2004年4月、<http://portal.opengeospatial.org/files/？artifact_id = 4700>。
[OGC.GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", OGC Best Practice 06-142r1, Version: 1.0, April 2007.
[OGC.GeoShape] Thomson、M.、C。Reed、「GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force（IETF）」、OGC Best Practice 06-142r1、バージョン：1.0、4月2007年
[RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation standard", RFC 1014, June 1987.
[RFC1014] Sun Microsystems、Inc。、「XDR：External Data Representation standard」、RFC 1014、1987年6月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、2003年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、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。、「Divamic Host Configuration Protocol（DHCPv4 and DHCPv6）Option for Civic Addresses Configuration Information」、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、「Presence Information Data Format Location Object（PIDF-LO）の改訂されたCivic Location Format」、RFC 5139、2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[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 Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月。
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010.
[RFC5962] Schulzrinne、H.、Singh、V.、Tschofenig、H。、およびM. Thomson、「Dynamic Extensions to the Presence Information Data Format Location Object（PIDF-LO）」、RFC 5962、2010年9月。
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and R. George, "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)", RFC 6848, January 2013.
[RFC6848] Winterbottom、J.、Thomson、M.、Barnes、R.、Rosen、B。、およびR. George、「Presence Information Data Format Location Object（PIDF-LO）でのCivicアドレス拡張の指定」、RFC 6848 、2013年1月。
[WGS84] US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000.
[WGS84]米国国立画像地図局、「国防総省（DoD）世界測地システム1984（WGS 84）、第3版」、NIMA TR8350.2、2000年1月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863]菅野博、藤本進、クライン、G、ベイトマン、A、カー、W、J。ピーターソン、「プレゼンス情報データフォーマット（PIDF）」、RFC 3863、2004年8月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「A Data Model for Presence」、RFC 4479、2006年7月。
Authors' Addresses
著者のアドレス
Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304 US
マーティントムソンMicrosoft 3210 Porter Drive Palo Alto、CA 94304 US
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net
Brian Rosen Neustar 470 Conrad Dr Mars, PA 16046 US
ブライアンローゼンノイスター470 Conrad Dr Mars、PA 16046 US
EMail: br@brianrosen.net
Dorothy Stanley Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 US
Dorothy Stanley Aruba Networks 1322 Crossman Ave Sunnyvale、CA 94089 US
EMail: dstanley@arubanetworks.com
Gabor Bajko Nokia 323 Fairchild Drive Mountain View, CA 94043 US
Gabor Bajko Nokia 323 Fairchild Drive Mountain View, CA 94043 US
EMail: gabor.bajko@nokia.com
Allan Thomson Lookingglass Cyber Solutions 1001 S Kenwood Avenue Baltimore, MD 21224 US
アラントムソンルッキンググラスサイバーソリューション1001 Sケンウッドアベニューボルチモア、MD 21224米国
EMail: athomson@lgscout.com