Network Working Group J. Winterbottom
Request for Comments: 5491 M. Thomson
Updates: 4119 Andrew Corporation
Category: Standards Track H. Tschofenig
Nokia Siemens Networks
March 2009
GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations
GEOPRIVプレゼンス情報データフォーマット場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing.
プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）仕様では、位置情報を表すために柔軟かつ汎用性の高い手段を提供します。情報は、それがどのように表現されるかに拘束する必要がある場合に発生する状況は、しかし、があります。このような状況では、実装する必要があるオプションの範囲が縮小されています。ルーティングアプリケーション用PIDF-LOに含まれる位置情報を使用することができることに関心が高まっています。アプリケーション間の正常な相互運用性を可能にするために、位置情報は、規範とより緊密に現在RFC 4119（PIDF-LO）で指定されるより拘束する必要があります。この文書では、制約表し、PIDF-LO内の位置を解釈する方法についての勧告を行います。さらに、ロケーションベースのルーティングに関与するアプリケーションによって実現することが必須である地理マークアップ言語（GML）3.1.1のサブセットをお勧めします。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Using Location Information ......................................4
3.1. Single Civic Location Information ..........................7
3.2. Civic and Geospatial Location Information ..................7
3.3. Manual/Automatic Configuration of Location Information .....8
3.4. Multiple Location Objects in a Single PIDF-LO ..............9
4. Geodetic Coordinate Representation .............................10
5. Geodetic Shape Representation ..................................10
5.1. Polygon Restrictions ......................................12
5.2. Shape Examples ............................................13
5.2.1. Point ..............................................13
5.2.2. Polygon ............................................14
5.2.3. Circle .............................................17
5.2.4. Ellipse ............................................17
5.2.5. Arc Band ...........................................19
5.2.6. Sphere .............................................21
5.2.7. Ellipsoid ..........................................22
5.2.8. Prism ..............................................24
6. Security Considerations ........................................26
7. Acknowledgments ................................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
The Presence Information Data Format Location Object (PIDF-LO) [RFC4119] is the recommended way of encoding location information and associated privacy policies. Location information in a PIDF-LO may be described in a geospatial manner based on a subset of Geography Markup Language (GML) 3.1.1 [OGC-GML3.1.1] or as civic location information [RFC5139]. A GML profile for expressing geodetic shapes in a PIDF-LO is described in [GeoShape]. Uses for the PIDF-LO are envisioned in the context of numerous location-based applications. This document makes recommendations for formats and conventions to make interoperability less problematic.
プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）[RFC4119]は、位置情報と関連付けられたプライバシーポリシーを符号化する推奨される方法です。位置PIDF-LOの情報は地理マークアップ言語（GML）3.1.1 [OGC-GML3.1.1]または市民の位置などの情報のサブセットに基づいて地理空間的に説明することができる[RFC5139]。 PIDF-LOに測地形状を表現するためのGMLプロファイルは[GeoShape]に記載されています。 PIDF-LOの用途は、多数のロケーションベースのアプリケーションのコンテキスト内で想定されます。この文書では、フォーマットやコンベンションのための推奨事項は、相互運用性はあまり問題にすることができます。
The PIDF-LO provides a general presence format for representing location information, and permits specification of location information relating to a whole range of aspects of a Target. The general presence data model is described in [RFC4479] and caters to a presence document to describe different aspects of the reachability of a presentity. Continuing this approach, a presence document may contain several GEOPRIV objects that specify different locations and aspects of reachability relating to a presentity. This degree of flexibility is important, and recommendations in this document make no attempt to forbid the usage of a PIDF-LO in this manner. This document provides a specific set of guidelines for building presence documents when it is important to unambiguously convey exactly one location.
PIDF-LOは、位置情報を表現するための一般的なプレゼンス・フォーマットを提供し、ターゲットの側面の全範囲に関連する位置情報の仕様を可能にします。一般的なプレゼンスデータモデルは、[RFC4479]に記載されており、プレゼンティティの到達可能性のさまざまな側面を記述するためにプレゼンス文書に応えています。このアプローチを続けると、プレゼンス文書は、プレゼンティティに関連するさまざまな場所と到達可能性の側面を指定するいくつかのGEOPRIVオブジェクトが含まれていてもよいです。この柔軟性の度合いが重要であり、この文書の推奨事項は、このようにPIDF-LOの使用を禁止する試みをしません。この文書では、明確に正確に一つの場所を伝えることが重要であるとき、プレゼンス文書を作成するためのガイドラインの特定のセットを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The definition for "Target" is taken from [RFC3693].
「ターゲット」の定義は、[RFC3693]から取得されます。
In this document a "discrete location" is defined as a place, point, area, or volume in which a Target can be found.
本書では、「離散位置」とは、標的を見つけることが可能な場所、点、領域、または体積として定義されます。
The term "compound location" is used to describe location information represented by a composite of both civic and geodetic information. An example of compound location might be a geodetic polygon describing the perimeter of a building and a civic element representing the floor in the building.
用語「化合物の位置は、」市民と測地情報の両方の複合で表される位置情報を記述するために使用されます。化合物の位置の例は、建物の周囲と建物のフロアを表す市民の要素を記述する測地ポリゴンかもしれません。
The term "method" in this document refers to the mechanism used to determine the location of a Target. This may be something employed by a location information server (LIS), or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information either to the Target or the Recipient.
この文書における用語「方法」は、標的の位置を決定するために使用される機構を指します。これは、位置情報サーバ（LIS）によって、または標的自体によって採用ものであってもよいです。それは、具体的に位置設定プロトコル（LCP）を参照していない標的またはレシピエントに位置情報のいずれかを送達するために使用されます。
The term "source" is used to refer to the LIS, node, or device from which a Recipient (Target or Third-Party) obtains location information.
用語「ソース」は、宛先（ターゲットまたはサードパーティ）が位置情報を取得し、そこからLIS、ノード、またはデバイスを指すために用いられます。
The PIDF format provides for an unbounded number of <tuple>, <device>, and <person> elements. Each of these elements contains a single <status> element that may contain more than one <geopriv> element as a child. Each <geopriv> element must contain at least the following two child elements: <location-info> element and <usage-rules> element. One or more elements containing location information are contained inside a <location-info> element.
PIDF形式は<タプル>、<デバイス>、および<人物>要素の無制限数を提供します。これらの各要素は子として複数の<geopriv>要素を含むことができ、単一の<状態>要素が含まれています。 <場所-info>要素と<用法・ルール>要素：各<geopriv>要素は、少なくとも二つの子要素を次のように含まれている必要があります。位置情報を含む1つの以上の要素は、<位置情報>要素内に含まれています。
Hence, a single PIDF document may contain an arbitrary number of location objects, some or all of which may be contradictory or complementary. Graphically, the structure of a PIDF-LO document can be depicted as shown in Figure 1.
したがって、単一PIDF文書が矛盾するまたは相補的であり得るいくつかまたは全てが位置オブジェクト、任意の数を含んでいてもよいです。図1に示すように、グラフ、PIDF-LOの文書の構造を示すことができます。
<presence> <tuple> -- #1 <status> <geopriv> -- #1 <location-info> location element #1 location element #2 ... location element #n <usage-rules> </geopriv> <geopriv> -- #2 <geopriv> -- #3 ... <geopriv> -- #m </status> </tuple> <device> <geopriv> -- #1 <location-info> location element(s) <usage-rules> </geopriv> <geopriv> -- #2 ... <geopriv> -- #m </device> <person> <geopriv> -- #1 <location-info> location element(s) <usage-rules> </geopriv> <geopriv> -- #2 ... <geopriv> -- #m </person> <tuple> -- #2 <device> -- #2 <person> -- #2 ... <tuple> -- #o </presence>
<プレゼンス> <タプル> - 1位<状態> <geopriv> - <利用ルール> #N＃1 <位置情報>位置要素＃1位置要素＃2 ...位置要素</ geopriv> < geopriv> - ＃2 <geopriv> - ＃3 ... <geopriv> - #M </ステータス> </タプル> <デバイス> <geopriv> - 1位<位置情報>位置要素（複数可）<利用ルール> </ geopriv> <geopriv> - ＃2 ... <geopriv> - #M </デバイス> <人> <geopriv> - 1位<位置情報>位置要素（複数可）<利用ルール> </ geopriv> <geopriv> - ＃2 ... <geopriv> - #M </人> <タプル> - ＃2 <デバイス> - ＃2 <人> - ＃2 ... <組> - #O </プレゼンス>
Figure 1: Structure of a PIDF-LO Document
図1：PIDF-LO文書の構造
All of these potential sources and storage places for location lead to confusion for the generators, conveyors, and consumers of location information. Practical experience within the United States National Emergency Number Association (NENA) in trying to solve these ambiguities led to a set of conventions being adopted. These rules do not have any particular order, but should be followed by creators and consumers of location information contained in a PIDF-LO to ensure that a consistent interpretation of the data can be achieved.
位置情報の発電機、コンベア、および消費者のための混乱に位置リードのためのこれらの潜在的な発生源と保管場所のすべて。これらのあいまいさを解決しようとする中、米国国立緊急番号協会（NENA）内の実際の経験が採用されている一連の規則につながりました。これらのルールは、任意の特定の順序を持っていないが、データの一貫性のある解釈を達成することができることを確実にするためにPIDF-LOに含まれる位置情報の作成者と消費者が従わなければなりません。
Rule #1: A <geopriv> element MUST describe a discrete location.
ルール＃1：<geopriv>要素は、離散的位置を記述する必要があります。
Rule #2: Where a discrete location can be uniquely described in more than one way, each location description SHOULD reside in a separate <tuple>, <device>, or <person> element; only one geopriv element per tuple.
ルール＃2：離散位置を一意複数の方法で記述することができ、各位置の説明は別個<タプル>に存在する必要があり、<デバイス>、または<人>要素。組ごとに1つのだけgeopriv要素。
Rule #3: Providing more than one <geopriv> element in a single presence document (PIDF) MUST only be done if the locations refer to the same place or are put into different element types. For example, one location in a <tuple>, a second location in a <device> element, and a third location in a <person> element.
ルール＃3：場所は同じ場所を参照するか、別の要素タイプに入れている場合は、単一のプレゼンス文書（PIDF）に複数の<geopriv>要素を提供するだけで行わなければなりません。例えば、<タプル>中の1つの場所、<デバイス>要素の第二の位置、及び、<人>要素の第3の位置。
This may occur if a Target's location is determined using a
series of different techniques or if the Target wishes to
represent her location as well as the location of her PC. In
general, avoid putting more than one location into a document
unless it makes sense to do so.
Rule #4: Providing more than one location chunk in a single <location-info> element SHOULD be avoided where possible. Rule #5 and Rule #6 provide further refinement.
ルール＃4：単一の<位置情報>に複数の場所チャンクを提供する要素は、可能な限り避けるべきです。ルール＃5とルール＃6は、更なる改良を提供しています。
Rule #5: When providing more than one location chunk in a single <location-info> element, the locations MUST be provided by a common source at the same time and by the same location determination method.
ルール＃5：単一の<位置情報>要素内の複数の位置のチャンクを提供する場合、位置が同時に共通ソースによって、同じ場所の決意方法によって提供されなければなりません。
Rule #6: Providing more than one location chunk in a single <location-info> element SHOULD only be used for representing compound location referring to the same place.
ルール＃6：単一の<位置情報>の複数の位置のチャンクを提供する要素は、同じ場所を参照化合物の位置を表すために使用されるべきです。
For example, a geodetic location describing a point, and a
civic location indicating the floor in a building.
Rule #7: Where the compound location is provided in a single <location-info> element, the coarse location information MUST be provided first.
ルール＃7：化合物の位置は、単一の<位置情報>要素内に設けられて、粗い位置情報が最初に提供されなければなりません。
For example, a geodetic location describing an area and a civic
location indicating the floor should be represented with the
area first followed by the civic location.
Rule #8: Where a PIDF document contains more than one <geopriv> element, the priority of interpretation is given to the first <device> element in the document containing a location. If no <device> element containing a location is present in the document, then priority is given to the first <tuple> element containing a location. Locations contained in <person> tuples SHOULD only be used as a last resort.
ルール＃8：PIDF文書が複数の<geopriv>要素が含まれ、解釈の優先順位は、位置を含む文書内の最初の<デバイス>要素に与えられます。位置を含むいかなる<デバイス>要素が文書内に存在しない場合、次に優先度が位置を含む最初の<タプル>要素に与えられます。 <人>に含まれている場所は、タプルは、最後の手段としてのみ使用されるべきです。
Rule #9: Where multiple PIDF documents can be sent or received together, say in a multi-part MIME body, and current location information is required by the recipient, then document selection SHOULD be based on document order, with the first document considered first.
複数PIDF文書が一緒に送信または受信することができ、マルチパートMIME本体に言うと、現在位置情報が受信者によって要求され、その文書の選択が最初に考慮最初のドキュメントと、ドキュメントの順序に基づくべきである：ルール＃9 。
The following examples illustrate the application of these rules.
以下の実施例は、これらの規則の適用を示します。
Jane is at a coffee shop on the ground floor of a large shopping mall. Jane turns on her laptop and connects to the coffee shop's WiFi hotspot; Jane obtains a complete civic address for her current location, for example, using the DHCP civic mechanism defined in [RFC4776]. A Location Object is constructed consisting of a single PIDF document, with a single <tuple> or <device> element, a single <status> element, a single <geopriv> element, and a single location chunk residing in the <location-info> element. This document is unambiguous, and should be interpreted consistently by receiving nodes if sent over the network.
ジェーンは大型ショッピングモールの階にコーヒーショップです。ジェーンは彼女のラップトップをオンにし、コーヒーショップのWiFiホットスポットに接続しています。ジェーンは[RFC4776]で定義されたDHCP市民のメカニズムを使用して、例えば、彼女の現在の場所のための完全な市民のアドレスを取得します。ロケーション・オブジェクトは、単一の<タプル>または<デバイス>要素は、単一の<状態>要素は、単一の<geopriv>要素と<位置情報に存在する単一の位置チャンクと、単一PIDF文書から成る構成されています>要素。この文書は明白であり、ネットワークを介して送信される場合にノードを受信することによって一貫して解釈されるべきです。
Mike is visiting his Seattle office and connects his laptop into the Ethernet port in a spare cube. In this case, location information is geodetic location, with the altitude represented as a building floor number. Mike's main location is the point specified by the geodetic coordinates. Further, Mike is on the second floor of the building located at these coordinates. Applying rules #6 and #7, the resulting compound location information is shown in Figure 2.
マイクは彼のシアトル事務所を訪問し、スペアキューブ内のイーサネットポートに彼のラップトップを接続しています。この場合、位置情報は、建物の床の数として表される高度で、測地位置です。マイクの主な場所は、測地座標で指定された点です。さらに、マイクはこれらの座標に配置され、建物の2階にあります。ルール＃6、＃7を適用すること、得られた化合物の位置情報は、図2に示されています。
<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:gml="http://www.opengis.net/gml" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:mike@seattle.example.com"> <dm:device id="mikepc"> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-43.5723 153.21760</gml:pos> </gml:Point> <cl:civicAddress> <cl:FLR>2</cl:FLR> </cl:civicAddress> </gp:location-info> <gp:usage-rules/> <gp:method>Wiremap</gp:method> </gp:geopriv> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> </dm:device> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" のxmlns：GP = "URN：IETF：paramsは：XML ：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net/gml" のxmlns：CL = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" エンティティ= "PRES。 mike@seattle.example.com "> <DM：デバイスID =" mikepc "> <GP：geopriv> <GP：場所-インフォメーション> <GML：ポイントsrsName =" 壷：OGC：DEF：CRS：EPSG :: 4326 「> <GML：POS> -43.5723 153.21760 </ GML：POS> </ GML：ポイント> <CL：civicAddress> <CL：FLR> 2 </ CL：FLR> </ CL：civicAddress> </ GP：位置-info> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> </ GP：geopriv>の<dm：のdeviceID> MAC：8asd7d7d70cf </ DM：のdeviceID>の<dm：タイムスタンプ> 2007- 06-22T20：57：29Z </ DM：タイムスタンプ> </ DM：デバイス> </プレゼンス>
Figure 2: PIDF-LO Containing a Compound Location
図2：化合物の位置を含むPIDF-LO
Loraine has a predefined civic location stored in her laptop, since she normally lives in Sydney, the address is for her Sydney-based apartment. Loraine decides to visit sunny San Francisco, and when she gets there, she plugs in her laptop and makes a call. Loraine's laptop receives a new location from the visited network in San Francisco. As this system cannot be sure that the preexisting and new location both describe the same place, Loraine's computer generates a new PIDF-LO and will use this to represent Loraine's location. If Loraine's computer were to add the new location to her existing PIDF location document (breaking rule #3), then the correct information may still be interpreted by the Location Recipient providing Loraine's system applies rule #9. In this case, the resulting order of location information in the PIDF document should be San Francisco first, followed by Sydney. Since the information is provided by different sources, rule #8 should also be applied and the information placed in different tuples with the tuple containing the San Francisco location first.
ロレインは、彼女が正常にシドニーに住んでいるので、アドレスは彼女のシドニーベースのアパートのためである、彼女のラップトップに保存されている事前定義された市民のロケーションに位置しています。ロレインは晴れ、サンフランシスコを訪問することを決定し、彼女がそこに着くとき、彼女は彼女のラップトップにプラグと呼び出しを行います。ロレインのラップトップは、サンフランシスコの訪問先ネットワークから新しい場所を受け取ります。このシステムは既存のと新しい場所が同じ場所を記述し、両方のことを確認することができないので、ロレインのコンピュータは新しいPIDF-LOを生成し、ロレインの位置を表すためにこれを使用します。ロレインのコンピュータが彼女の既存のPIDFのロケーション文書に新しい場所を追加した場合（速報ルール＃3）、その後、正しい情報はまだロレインのシステムがルール＃9を適用提供する場所の受信者によって解釈することができます。この場合、PIDF文書内の位置情報の結果として得られる順序は、シドニーに続いて、最初のサンフランシスコでなければなりません。情報は、異なるソースによって提供されているので、ルール＃8はまた、適用されるべき情報は、第サンフランシスコ位置を含むタプルと異なるタプルに入れました。
Vanessa has her PC with her at the park, but due to a misconfiguration, her PC reports her location as being in the office. The resulting PIDF-LO will have a <device> element showing the location of Vanessa's PC as the park, and a <person> element saying that Vanessa is in her office.
ヴァネッサは公園で彼女と彼女のPCを持っていますが、原因設定ミスに、彼女のPCは、オフィスにいるとして彼女の位置を報告します。その結果PIDF-LOは公園としてヴァネッサのPCの場所を示す<デバイス>要素、そしてヴァネッサは彼女のオフィスにあると言って、<人>要素を持つことになります。
<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: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:RDBR>Campbell Street</ca:RDBR> <ca:LMK> Gilligan's Island </ca:LMK> <ca:LOC>Corner</ca:LOC> <ca:NAM> Video Rental Store </ca:NAM> <ca:PC>2500</ca:PC> <ca:ROOM> Westerns and Classics </ca:ROOM> <ca:PLC>store</ca:PLC> <ca:POBOX>Private Box 15</ca:POBOX> </ca:civicAddress> </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> <dm:person id="ness"> <gp:geopriv> <gp:location-info> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-34.410649 150.87651</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" のxmlns：GP = "URN：IETF：paramsは：XML ：NS：PIDF：geopriv10" のxmlns：CA = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" のxmlns：GML = "http://www.opengis.net/gml" のxmlns：のGS =」 http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：ness@example.com">の<dm：デバイスID = "nesspc-1"> <GP：geopriv> <GP：ロケーション情報> <CA：civicAddressのxml：LANG = "EN-AU"> <CA：国> AU </ CA：国> <CA：A1> NSW </ CA：A1> <CA：A3>ウロンゴン</ CA：A3> <CA：A4>北ウロンゴン</ CA：A4> <CA：RD>フリンダース</ CA：RD> <CA：STS>ストリート</ CA：STS> <CA：RDBR>キャンベルストリート</ CA：RDBR> <CA：LMK>ギリガン君SOS </ CA：LMK> <CA：LOC>コーナー</ CA：LOC> <CA：NAM>ビデオレンタル店</ CA：NAM> <CA：PC> 2500 </ CA：PC > <CA：ROOM>西部劇とクラシック</ CA：ROOM> <CA：PLC>ストア</ CA：PLC> <CA：POBOX>専用ボックス15 </ CA：POBOX> </ CA：civicAddress> </ GP ：位置情報> <GP：利用ルール/> <GP：方法> GPS </ GP：方法> </ GP：geopriv>の<dm：のdeviceID> MAC：1234567890ab </ DM：のdeviceID>の<dm：タイムスタンプ> 2007-06-22T20：57：29Z < / DM：タイムスタンプ> </ DM：デバイス>の<dm：人物ID = "らし"> <GP：geopriv> <GP：ロケーション情報> <GS：サークルsrsName = "URN：OGC：DEF：CRS：EPSG： ：4326 "> <GML：POS> -34.410649 150.87651 </ GML：POS> <GS：半径UOM =" URN：OGC：DEF：UOM：EPSG :: 9001" >
30 </gs:radius> </gs:Circle> </gp:location-info> <gp:usage-rules/> <gp:method>Manual</gp:method> </gp:geopriv> <dm:timestamp>2007-06-24T12:28:04Z</dm:timestamp> </dm:person> </presence>
30 </ GS：半径> </ GS：サークル> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>マニュアル</ GP：方法> </ GP：geopriv>の<dm：タイムスタンプ> 2007-06-24T12：28：04Z </ DM：タイムスタンプ> </ DM：人> </プレゼンス>
Figure 3: PIDF-LO Containing Multiple Location Objects
図3：複数の場所のオブジェクトを含むPIDF-LO
The geodetic examples provided in RFC 4119 [RFC4119] are illustrated using the <gml:location> element, which uses the <gml:coordinates> element inside the <gml:Point> element, and this representation has several drawbacks. Firstly, it has been deprecated in later versions of GML (3.1 and beyond) making it inadvisable to use for new applications. Secondly, the format of the coordinates type is opaque and so can be difficult to parse and interpret to ensure consistent results, as the same geodetic location can be expressed in a variety of ways. The PIDF-LO Geodetic Shapes specification [GeoShape] provides a specific GML profile for expressing commonly used shapes using simple GML representations. The shapes defined in [GeoShape] are the recommended shapes to ensure interoperability.
使用<位置GML>要素、<GML：座標は> RFC 4119 [RFC4119]に設け測地例は、使用して示されている内部要素<GML：ポイント>要素、及びこの表現は、いくつかの欠点を有します。第一に、それは新しいアプリケーションのために使用することが得策作るGMLのそれ以降のバージョン（3.1以降）で廃止されました。第二に、座標タイプのフォーマットは不透明であり、同じ測地位置は、様々な方法で表現することができるように、一貫性のある結果を確保するために解析し、解釈が困難であることができます。 PIDF-LO測地形状仕様は、[GeoShape】簡単GML表現を使用して一般的に使用される形状を表現するため、特定のGMLプロフィールを提供します。 [GeoShape]で定義された形状は、相互運用性を確保するための推奨形状です。
The cellular mobile world today makes extensive use of geodetic-based location information for emergency and other location-based applications. Generally, these locations are expressed as a point (either in two or three dimensions) and an area or volume of uncertainty around the point. In theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume. In practice, most systems use the point as an absolute value and ignore the uncertainty. It is difficult to determine if systems have been implemented in this manner for simplicity, and even more difficult to predict if uncertainty will play a more important role in the future. An important decision is whether an uncertainty area should be specified.
携帯モバイルの世界は本日、緊急時やその他のロケーションベースのアプリケーションのための測地ベースの位置情報を多用します。一般に、これらの位置は、点（2つのまたは三次元における）点の周りの不確実性の領域又は体積として表されます。理論的には、面積または体積は、ユーザが発見され、比較的高い確率を有する、カバレッジを示し、点は領域又はボリュームの重心を定義する便利な手段です。実際に、ほとんどのシステムは、絶対値としてポイントを使用して不確実性を無視します。システムが不確実性は、将来的にはより重要な役割を果たしているかどうかを予測するために簡単にするために、このように実装され、さらに困難されているかどうかを判断することは困難です。重要な決定は、不確定領域を指定する必要があるかどうかです。
The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight shape types, most of which are easily translated into shape definitions used in other applications and protocols, such as the Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For completeness, the shapes defined in [GeoShape] are listed below:
PIDF-LO測地形状仕様[GeoShape]は容易にそのようなオープン・モバイル・アライアンス（OMA）モバイルロケーションプロトコル（MLP）などの他のアプリケーションとプロトコルで使用される形状の定義に変換されほとんどが8つの形状の種類を定義します。完全性のために、[GeoShape]で定義された形状は、以下に記載されています。
o Point (2d and 3d)
Oポイント（2Dおよび3D）
o Polygon (2d)
ポリゴン（2D）O
o Circle (2d)
Oサークル（2D）
o Ellipse (2d)
お えっぃｐせ （２ｄ）
o Arc band (2d)
Oアークバンド（2D）
o Sphere (3d)
O球（3D）
o Ellipsoid (3d)
O楕円体（3D）
o Prism (3d)
Oプリズム（3D）
The above-listed shapes MUST be implemented.
上に列挙した形状が実現されなければなりません。
The GeoShape specification [GeoShape] also describes a standard set of coordinate reference systems (CRS), unit of measure (UoM) and conventions relating to lines and distances. The use of the world geodetic system 1984 (WGS84) [WGS84] coordinate reference system and the usage of European petroleum survey group (EPSG) code 4326 (as identified by the URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) for two-dimensional (2d) shape representations and EPSG 4979 (as identified by the URN urn:ogc:def:crs:EPSG::4979) for three-dimensional (3d) volume representations is mandated. Distance and heights are expressed in meters using EPSG 9001 (as identified by the URN urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either degrees or radians. Measures in degrees MUST be identified by the URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be identified by the URN urn:ogc:def:uom:EPSG::9101. Angles representing bearings are measured in a clockwise direction from Northing, as defined by the WGS84 CRS, not magnetic north.
GeoShape仕様は[GeoShape]も参照システム（CRS）、測定単位（UOM）と線との距離に関連する規則を座標の標準セットを記述する。 OGC：DEF：世界測地系1984（WGS84）[WGS84]基準システム及び欧州石油調査グループ（EPSG）コードURNのURNによって識別される4326（の使用座標を使用CRS：EPSG :: 4326、[ CRS-URN二次元（2D）形状表現のための]）及び4979 EPSG（URNのURNによって識別される：OGC：DEF：CRS：EPSG :: 4979）は、3次元（3D）ボリューム表現のために義務付けられています。 （：OGC：DEF：UOM：EPSG :: 9001 URNのURNによって識別される）までの距離と高さは、EPSG 9001を使用して、メートル単位で表されます。角度の対策は度またはラジアンのいずれかを使用しなければなりません。 OGC：：DEF：UOM：ラジアンで対策がURN骨壷で識別されなければならないEPSG :: 9102：OGC：DEF：UOM：EPSG :: 9101度での対策は、URN骨壷によって識別される必要があります。 WGS84 CRS、磁気ない北によって定義されるようなベアリングを表す角度は、北距から時計回りに測定されます。
Implementations MUST specify the CRS using the srsName attribute on the outermost geometry element. The CRS MUST NOT be respecified or changed for any sub-elements. The srsDimension attribute SHOULD be omitted, since the number of dimensions in these CRSs is known. A CRS MUST be specified using the above URN notation only; implementations do not need to support user-defined CRSs.
実装は、最も外側の幾何学的要素のsrsName属性を使用してCRSを指定しなければなりません。 CRSは、任意のサブ要素に対して再または変更しないでください。これらのCRSの次元数が知られているのでsrsDimension属性は、省略されてください。 CRSは、上記URN表記を使用して指定されなければなりません。実装は、ユーザー定義のCRSをサポートする必要はありません。
Numerical values for coordinates and measures are expressed using the lexical representation for "double" defined in [W3C.REC-xmlschema-2-20041028]. Leading zeros and trailing zeros past the decimal point are not significant; for instance "03.07500" is equivalent to "3.075".
座標および指標の数値で定義された「二重」の語彙表現を用いて表現されている[W3C.REC-XMLSCHEMA-2から20041028]。小数点過去の先行ゼロと末尾のゼロは重要ではありません。 「03.07500」例えば「3.075」に相当します。
It is RECOMMENDED that uncertainty is expressed at a confidence of 95% or higher. Specifying a convention for confidence enables better use of uncertainty values.
不確実性は95％以上の信頼で発現することをお勧めします。自信のための規則を指定すると、不確定値をより有効に利用することができます。
The polygon shape type defined in [GeoShape] intentionally does not place any constraints on the number of vertices that may be included to define the bounds of a polygon. This allows arbitrarily complex shapes to be defined and conveyed in a PIDF-LO. However, where location information is to be used in real-time processing applications, such as location-dependent routing, having arbitrarily complex shapes consisting of tens or even hundreds of points could result in significant performance impacts. To mitigate this risk, Polygon shapes SHOULD be restricted to a maximum of 15 points (16 including the repeated point) when the location information is intended for use in real-time applications. This limit of 15 points is chosen to allow moderately complex shape definitions while at the same time enabling interoperation with other location transporting protocols such as those defined in the 3rd Generation Partnership Project (3GPP) (see [3GPP.23.032]) and OMA where the 15-point limit is already imposed.
意図[GeoShape]で定義された多角形状のタイプは、多角形の境界を定義するために含めることができる頂点の数に制約を置きません。これは、任意の複雑な形状がPIDF-LOで定義されて搬送されることを可能にします。しかし、ここで位置情報は、ポイント数十あるいは数百からなる任意の複雑な形状は、大幅なパフォーマンスの影響をもたらす可能性を有する、そのような位置依存型ルーティングなどのリアルタイム処理用途に使用されます。位置情報がリアルタイムアプリケーションで使用するために意図されている場合は、このリスクを軽減するために、多角形の形状が15点（繰り返し点を含む16）の最大値に制限されるべきです。 15点のこの制限は、第3世代パートナーシッププロジェクト（3GPP）で定義されたもののような他の場所輸送プロトコルとの相互運用を可能にすると同時に、及びOMA（[3GPP.23.032]を参照）しながら、適度に複雑な形状の定義を可能にするように選択されます15点の制限はすでに課されています。
The edges of a polygon are defined by the shortest path between two points in space (not a geodesic curve). Two-dimensional points MAY be interpreted as having a zero value for their altitude component. To avoid significant errors arising from potential geodesic interpolation, the length between adjacent vertices SHOULD be restricted to a maximum of 130 km. More information relating to this restriction is provided in [GeoShape].
ポリゴンのエッジは、空間の2点間の最短経路（ない測地線）によって定義されます。二次元の点は、それらの高度成分のゼロ値を有するものとして解釈されてもよいです。潜在的な測地補間から生じる重大なエラーを回避するために、隣接する頂点間の長さは、130キロの最大値に制限されるべきです。この制限に関する詳細は、[GeoShape]で提供されます。
A connecting line SHALL NOT cross another connecting line of the same Polygon.
接続ラインは同じポリゴンの別の接続線を越えないものとします。
Polygons MUST be defined with the upward normal pointing up. This is accomplished by defining the vertices in a counter-clockwise direction.
ポリゴンは、上向きの通常のポインティングアップで定義する必要があります。これは、反時計回りの方向に頂点を定義することによって達成されます。
Points specified in a polygon using three-dimensional coordinates MUST all have the same altitude.
三次元座標を用いて、ポリゴンで指定された点が全て同じ高度を持たなければなりません。
This section provides some examples of where some of the more complex shapes are used, how they are determined, and how they are represented in a PIDF-LO. Complete details on all of the GeoShape types are provided in [GeoShape].
このセクションでは、それらがどのように決定されるか、より複雑な形状の一部が使用される場合のいくつかの例を提供し、どのようにそれらがPIDF-LOで表されています。 GeoShapeタイプのすべての完全な詳細は[GeoShape]で提供されています。
The point shape type is the simplest form of geodetic location information (LI), which is natively supported by GML. The gml:Point element is used when there is no known uncertainty. A point also forms part of a number of other geometries. A point may be specified using either WGS 84 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). Figure 4 shows a 2d point:
点状型は、ネイティブGMLに支持されている測地位置情報（LI）の最も単純な形態です。 GML：既知の不確実性が存在しない場合にポイント要素が使用されています。ポイントは、他の幾何学的形状の多数の一部を形成します。点は、WGS 84（緯度、経度）またはWGS 84（緯度、経度、高度）のいずれかを使用して指定することができます。図4は、2D点を示しています。
<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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:point2d@example.com"> <dm:device id="point2d"> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-34.407 150.883</gml:pos> </gml:Point> </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>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" のxmlns：GP = "URN：IETF：paramsは：XML ：NS：PIDF：geopriv10" のxmlns：CL = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" のxmlns：GML = "http://www.opengis.net/gml" エンティティ= "PRES。 point2d@example.com "> <DM：デバイスID =" Point2Dの "> <GP：geopriv> <GP：場所-インフォメーション> <GML：ポイントsrsName =" 壷：OGC：DEF：CRS：EPSG :: 4326" > <GML：POS> -34.407 150.883 </ GML：POS> </ GML：ポイント> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> </ GP：geopriv>の<dm：のdeviceID> MAC：1234567890ab </ DM：のdeviceID>の<dm：タイムスタンプ> 2007-06-22T20：57：29Z </ DM：タイムスタンプ> </ DM：デバイス> </プレゼンス>
Figure 4: PIDF-LO Containing a Two-Dimensional Point
図4：二次元点を含むPIDF-LO
Figure 5 shows a 3d point:
図5は、3Dポイントを示しています。
<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:gml="http://www.opengis.net/gml" entity="pres:point3d@example.com"> <dm:device id="point3d"> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4979" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>-34.407 150.883 24.8</gml:pos> </gml:Point> </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>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" のxmlns：GP = "URN：IETF：paramsは：XML ：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net/gml" エンティティ= "PRES：point3d@example.com">の<dm：デバイスID = "たPoint3D"> <GP：geopriv > <GP：場所-インフォメーション> <GML：ポイントsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979" のxmlns：GML = "http://www.opengis.net/gml"> <GML：POS > -34.407 150.883 24.8 </ GML：POS> </ GML：ポイント> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> </ GP：geopriv >の<dm：のdeviceID> MAC：1234567890ab </ DM：のdeviceID>の<dm：タイムスタンプ> 2007-06-22T20：57：29Z </ DM：タイムスタンプ> </ DM：デバイス> </プレゼンス>
Figure 5: PIDF-LO Containing a Three-Dimensional Point
図5：三次元点を含むPIDF-LO
The polygon shape type may be used to represent a building outline or coverage area. The first and last points of the polygon have to be the same. For example, looking at the hexagon in Figure 6 with vertices, A, B, C, D, E, and F. The resulting polygon will be defined with 7 points, with the first and last points both having the coordinates of point A.
ポリゴン形状タイプは、建物の輪郭またはカバレッジエリアを表すために使用されてもよいです。多角形の最初と最後の点は同じでなければなりません。例えば、最初と最後の点で、得られたポリゴンが7点で定義される頂点を有する図6、A、B、C、D、E、およびFに六角形見両方点Aの座標を有します
F--------------E
/ \
/ \
/ \
A D
\ /
\ /
\ /
B--------------C
Figure 6: Example of a Polygon
図6：ポリゴンの例
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" entity="pres:hexagon@example.com"> <tuple id="polygon-pos"> <status> <gp:geopriv> <gp:location-info> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:pos>43.311 -73.422</gml:pos> <!--A--> <gml:pos>43.111 -73.322</gml:pos> <!--F--> <gml:pos>43.111 -73.222</gml:pos> <!--E--> <gml:pos>43.311 -73.122</gml:pos> <!--D--> <gml:pos>43.411 -73.222</gml:pos> <!--C--> <gml:pos>43.411 -73.322</gml:pos> <!--B--> <gml:pos>43.311 -73.422</gml:pos> <!--A--> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gp:location-info> <gp:usage-rules/> <gp:method>Wiremap</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML "エンティティ= "PRES：hexagon@example.com"> <タプルID = "ポリゴン-POS"> <状態> <GP：geopriv> <GP：ロケーション情報> <GML：ポリゴンsrsName =" URN：OGC ：DEF：CRS：EPSG :: 4326" > <GML：外装> <GML：LinearRing> <GML：POS> 43.311 -73.422 </ GML：！POS> < - A - > <GML：POS> 43.111 - 73.322 </ GML：POS> <！ - F - > <GML：POS> 43.111 -73.222 </ GML：POS> < - E - > <！GML：POS> 43.311 -73.122 </ GML：POS > <！ - D - > <GML：POS> 43.411 -73.222 </ GML：POS> < - C - > <GML：POS> 43.411 -73.322 </ GML：POS> < - B - > <GML：POS> 43.311 -73.422 </ GML：POS> < - A - > </ GML：！LinearRing> </ GML：外装> </ GML：ポリゴン> </ GP：位置情報> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> </ GP：geopriv> </状態> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 7: PIDF-LO Containing a Polygon
図7：多角形を含むPIDF-LO
In addition to the form shown in Figure 7, GML supports a posList that provides a more compact representation for the coordinates of the Polygon vertices than the discrete pos elements. The more compact form is shown in Figure 8. Both forms are permitted.
図7に示す形態の他に、GMLは、離散POS要素よりポリゴンの頂点の座標のよりコンパクトな表現を提供POSLISTをサポートします。よりコンパクトな形態は、両方の形態が許可されている図8に示されています。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" entity="pres:hexagon@example.com"> <tuple id="polygon-poslist"> <status> <gp:geopriv> <gp:location-info> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:posList> 43.311 -73.422 43.111 -73.322 43.111 -73.222 43.311 -73.122 43.411 -73.222 43.411 -73.322 43.311 -73.422 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gp:location-info> <gp:usage-rules/> <gp:method>Wiremap</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML "エンティティ= "PRES：hexagon@example.com"> <タプルID = "ポリゴンPOSLIST"> <状態> <GP：geopriv> <GP：ロケーション情報> <GML：ポリゴンsrsName =" URN：OGC ：DEF：CRS：EPSG :: 4326" > <GML：外装> <GML：LinearRing> <GML：POSLIST> 43.311 -73.422 43.111 -73.322 43.111 -73.222 43.311 -73.122 43.411 -73.222 43.411 -73.322 43.311 -73.422 </ GML ：POSLIST> </ GML：LinearRing> </ GML：外装> </ GML：ポリゴン> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> < / GP：geopriv> </状態> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 8: Compact Form of a Polygon Expressed in a PIDF-LO
図8：PIDF-LOで発現多角形のコンパクトなフォーム
The circular area is used for coordinates in two-dimensional CRSs to describe uncertainty about a point. The definition is based on the one-dimensional geometry in GML, gml:CircleByCenterPoint. The center point of a circular area is specified by using a two-dimensional CRS; in three dimensions, the orientation of the circle cannot be specified correctly using this representation. A point with uncertainty that is specified in three dimensions should use the sphere shape type.
円形領域は、点に関する不確実性を記述するために二次元のCRSの座標に使用されます。 CircleByCenterPoint：定義はGML、GMLの1次元形状に基づいています。円形領域の中心点は、二次元CRSを使用して指定されます。三次元では、円の方向は、この表現を使用して正しく指定することができません。三次元で指定された不確実性を持つ点は、球体形状の種類を使用する必要があります。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:circle@example.com"> <tuple id="circle"> <status> <gp:geopriv> <gp:location-info> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>42.5463 -73.2512</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> 850.24 </gs:radius> </gs:Circle> </gp:location-info> <gp:usage-rules/> <gp:method>OTDOA</gp:method> </gp:geopriv> </status> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：circle@example.com"> <タプルID = "円"> <状態> <GP：geopriv> <GP：ロケーション情報> <GS：サークルsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML：POS> 42.5463 -73.2512 </ GML：POS> <GS：半径UOM = "URN ：OGC：DEF：UOM：EPSG :: 9001" > 850.24 </ gsは：半径> </ GS：サークル> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法> OTDOA </ GP：方法> </ GP：geopriv> </状態> </タプル> </プレゼンス>
Figure 9: PIDF-LO Containing a Circle
図9：サークルを含むPIDF-LO
An elliptical area describes an ellipse in two-dimensional space. The ellipse is described by a center point, the length of its semi-major and semi-minor axes, and the orientation of the semi-major axis. Like the circular area (Circle), the ellipse MUST be specified using the two-dimensional CRS.
楕円領域は、二次元空間における楕円を記述する。楕円の中心点、その半主要半短軸の長さ、および半長軸の配向によって記載されています。円形領域（サークル）のように、楕円は二次元のCRSを使用して指定されなければなりません。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:Ellipse@somecell.example.com"> <tuple id="ellipse"> <status> <gp:geopriv> <gp:location-info> <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>42.5463 -73.2512</gml:pos> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> 1275 </gs:semiMajorAxis> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> 670 </gs:semiMinorAxis> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> 43.2 </gs:orientation> </gs:Ellipse> </gp:location-info> <gp:usage-rules/> <gp:method>Device-Assisted_A-GPS</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：Ellipse@somecell.example.com"> <タプルID = "楕円"> <状態> <GP： geopriv> <GP：ロケーション情報>、<GS：楕円srsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：POS> 42.5463 -73.2512 </ GML：POS> <GS：semiMajorAxis UOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 1275 </ GS：semiMajorAxis> <GS：semiMinorAxis UOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> 670 </ GS：semiMinorAxis> <GS：配向UOM = "URN：OGC：DEF：UOM：EPSG :: 9102"> 43.2 </ gsは：配向> </ GS：楕円> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>デバイス-Assisted_A-GPS </ GP：方法> </ GP：geopriv> </状態> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 10: PIDF-LO Containing an Ellipse
図10：楕円を含むPIDF-LO
The gml:pos element indicates the position of the center, or origin, of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements are the length of the semi-major and semi-minor axes, respectively. The gs:orientation element is the angle by which the semi-major axis is rotated from the first axis of the CRS towards the second axis. For WGS 84, the orientation indicates rotation from Northing to Easting, which, if specified in degrees, is roughly equivalent to a compass bearing (if magnetic north were the same as the WGS north pole). Note: An ellipse with equal major and minor axis lengths is a circle.
GML：POS要素は、楕円の中心の位置、又は起源を示します。 GS：semiMajorAxisおよびGS：semiMinorAxis要素はそれぞれ、半メジャー及び半短軸の長さです。 GS：配向要素は、半長軸が第2の軸に向かってCRSの第一の軸から回転させる角度です。 WGS 84のために、向きが東距に北距からの回転を示し、（磁北はWGS北極と同じであった場合）、度で指定されている場合、コンパス方位とほぼ等価です。注：等しい長軸と短軸の長さを有する楕円が円です。
The arc band shape type is commonly generated in wireless systems where timing advance or code offsets sequences are used to compensate for distances between handsets and the access point. The arc band is represented as two radii emanating from a central point, and two angles that represent the starting angle and the opening angle of the arc. In a cellular environment, the central point is nominally the location of the cell tower, the two radii are determined by the extent of the timing advance, and the two angles are generally provisioned information.
円弧帯状のタイプは、一般に、タイミングアドバンス又はコードオフセット配列がハンドセットとアクセスポイントの間の距離を補償するために使用される無線システムで生成されます。アークバンドは中心点から発する二つの半径、及び開始角と円弧の開口角度を表す2つの角度として表されます。セルラ環境では、中心点は公称セルタワーの位置であり、二つの半径がタイミングアドバンスの程度によって決定され、2つの角度は、一般的に情報をプロビジョニングしています。
For example, Paul is using a cellular wireless device and is 7 timing advance symbols away from the cell tower. For a GSM-based network, this would place Paul roughly between 3,594 meters and 4,148 meters from the cell tower, providing the inner and outer radius values. If the start angle is 20 degrees from north, and the opening angle is 120 degrees, an arc band representing Paul's location would look similar to Figure 11.
例えば、ポールは、携帯無線装置を使用し、7つのタイミングアドバンスシンボル離れセルタワーからです。 GSMベースのネットワークの場合、これは、内側と外側の半径値を提供する、セルタワーから概ね3594メートルと4148メートルの間でポールを置くであろう。開始角は北から20度であり、開口角が120度である場合、ポールの位置を表すアークバンドは図11のようになります。
N ^ ,.__
| a(s) / `-.
| 20 / `-.
|--. / `.
| `/ \
| /__ \
| . `-. \
| . `. \
|. \ \ .
---c-- a(o) -- | | -->
|. / 120 ' | E
| . / '
| . / ;
.,' /
r(i)`. /
(3594m) `. /
`. ,'
`. ,'
r(o)`'
(4148m)
Figure 11: Example of an Arc Band
図11：アークバンドの例
The resulting PIDF-LO is shown in Figure 12.
得PIDF-LOは、図12に示されています。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:paul@somecell.example.com"> <tuple id="arcband"> <status> <gp:geopriv> <gp:location-info> <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-43.5723 153.21760</gml:pos> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> 3594 </gs:innerRadius> <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001"> 4148 </gs:outerRadius> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> 20 </gs:startAngle> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> 20 </gs:openingAngle> </gs:ArcBand> </gp:location-info> <gp:usage-rules/> <gp:method>TA-NMR</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：paul@somecell.example.com"> <タプルID = "arcband"> <状態> <GP： geopriv> <GP：ロケーション情報>、<GS：ArcBand srsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：POS> -43.5723 153.21760 </ GML：POS> <GS：innerRadiusのUOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 3594 </ GS：innerRadius> <GS：outerRadiusのUOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> 4148 </ GS：outerRadius> <GS：startAngleののUOM = "URN：OGC：DEF：UOM：EPSG :: 9102"> 20 </ gsは：startAngleの> <GS：openingAngleのUOM = "URN：OGC：DEF：UOM：EPSG :: 9102"> 20 </ GS：openingAngle> </ GS：ArcBand> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法> TA-NMR </ GP：方法> </ GP：geopriv> </ステータス> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 12: PIDF-LO Containing an Arc Band
図12：アークバンドを含むPIDF-LO
An important note to make on the arc band is that the center point used in the definition of the shape is not included in resulting enclosed area, and that Target may be anywhere in the defined area of the arc band.
アーク帯にすることが重要音符は、形状の定義に使用される中心点が囲まれた領域が得られるに含まれていない、そしてそのターゲットがアーク帯域の定義された領域内のどこであってもよいということです。
The sphere is a volume that provides the same information as a circle in three dimensions. The sphere has to be specified using a three-dimensional CRS. Figure 13 shows the sphere shape type, which is identical to the circle example, except for the addition of an altitude in the provided coordinates.
球体は、三次元の円と同じ情報を提供する量です。球は、3次元のCRSを使用して指定する必要があります。図13は設け座標における高度の添加を除いて、円形の例と同一である、球体形状の種類を示しています。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:sphere@example.com"> <tuple id="sphere"> <status> <gp:geopriv> <gp:location-info> <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos>42.5463 -73.2512 26.3</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> 850.24 </gs:radius> </gs:Sphere> </gp:location-info> <gp:usage-rules/> <gp:method>Device-Based_A-GPS</gp:method> </gp:geopriv> </status> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：sphere@example.com"> <タプルID = "球"> <状態> <GP：geopriv> <GP：ロケーション情報> <GS：スフィアsrsName = "URN：OGC：DEF：CRS：EPSG :: 4979"> <GML：POS> 42.5463 -73.2512 26.3 </ GML：POS> <GS：半径UOM =」 URN：OGC：DEF：UOM：EPSG :: 9001" > 850.24 </ gsは：半径> </ GS：スフィア> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>デバイス - Based_A-GPS </ GP：方法> </ GP：geopriv> </状態> </タプル> </プレゼンス>
Figure 13: PIDF-LO Containing a Sphere
図13：スフィアを含むPIDF-LO
The ellipsoid is the volume most commonly produced by GPS systems. It is used extensively in navigation systems and wireless location networks. The ellipsoid is constructed around a central point specified in three dimensions, and three axes perpendicular to one another are extended outwards from this point. These axes are defined as the semi-major (M) axis, the semi-minor (m) axis, and the vertical (v) axis, respectively. An angle is used to express the orientation of the ellipsoid. The orientation angle is measured in degrees from north, and represents the direction of the semi-major axis from the center point.
楕円体は、最も一般的にGPSシステムによって生成ボリュームです。これは、ナビゲーションシステムおよびワイヤレス位置検出ネットワークで広く使用されています。楕円は、三次元で指定された中心点の周囲に構築され、かつ互いに直交する3つの軸は、この点から外側に延びています。これらの軸は、それぞれ、半メジャー（M）軸、半マイナー（M）軸、及び垂直（V）軸として定義されます。角度は、楕円の向きを発現するために使用されます。配向角は北からの角度で測定し、中心点からの半長軸の方向を示しています。
\
_.-\""""^"""""-._
.' \ | `.
/ v m \
| \ | |
| -c ----M---->|
| |
\ /
`._ _.'
`-...........-'
Figure 14: Example of an Ellipsoid
図14：楕円体の例
A PIDF-LO containing an ellipsoid appears as shown in Figure 15.
図15に示すように楕円を含むPIDF-LOが表示されます。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:somone@gpsreceiver.example.com"> <tuple id="ellipsoid"> <status> <gp:geopriv> <gp:location-info> <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos>42.5463 -73.2512 26.3</gml:pos> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> 7.7156 </gs:semiMajorAxis> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> 3.31 </gs:semiMinorAxis> <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001"> 28.7 </gs:verticalAxis> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> 90 </gs:orientation> </gs:Ellipsoid> </gp:location-info> <gp:usage-rules/> <gp:method>Hybrid_A-GPS</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：somone@gpsreceiver.example.com"> <タプルID = "楕円"> <状態> <GP： geopriv> <GP：ロケーション情報>、<GS：楕円srsName = "壷：OGC：DEF：CRS：EPSG :: 4979"> <GML：POS> 42.5463 -73.2512 26.3 </ GML：POS> <GS：semiMajorAxis UOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> 7.7156 </のGS：semiMajorAxis> <GS：semiMinorAxisのUOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> 3.31 </のGS：semiMinorAxis > <GS：垂直軸のUOM = "壷：OGC：DEF：UOM：EPSG :: 9001"> 28.7 </ gsと：垂直軸> <GS：オリエンテーションUOM = "壷：OGC：DEF：UOM：EPSG :: 9102"> 90 </ gsは：配向> </ GS：楕円> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法> Hybrid_A-GPS </ GP：方法> </ GP：geopriv> < /ステータス> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 15: PIDF-LO Containing an Ellipsoid
図15：楕円を含むPIDF-LO
A prism may be used to represent a section of a building or range of floors of building. The prism extrudes a polygon by providing a height element. It consists of a base made up of coplanar points defined in 3 dimensions all at the same altitude. The prism is then an extrusion from this base to the value specified in the height element. The height of the Prism MUST be a positive value. The first and last points of the polygon have to be the same.
プリズムは、建物のフロアの建物または範囲の部分を表すために使用されてもよいです。プリズムは、高さ要素を提供することによって、ポリゴンを押し出します。それはすべて同じ高度で3次元で定義された同一平面上の点で構成されたベースから成ります。プリズムは、その後、高さ要素で指定された値に、この基部から押出されます。プリズムの高さは正の値でなければなりません。多角形の最初と最後の点は同じでなければなりません。
For example, looking at the cube in Figure 16: if the prism is extruded from the bottom up, then the polygon forming the base of the prism is defined with the points A, B, C, D, A. The height of the prism is the distance between point A and point E in meters.
例えば、図16のキューブを見て：プリズムの下から押し出される場合、プリズムの基部を構成するポリゴンは、プリズムの高さの点A、B、C、D、Aと定義されていますメートル単位で点Aと点Eとの間の距離です。
G-----F
/| /|
/ | / |
H--+--E |
| C--|--B
| / | /
|/ |/
D-----A
Figure 16: Example of a Prism
図16：プリズムの例
The resulting PIDF-LO is shown in Figure 17.
得PIDF-LOは、図17に示されています。
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" entity="pres:mike@someprism.example.com"> <tuple id="prism"> <status> <gp:geopriv> <gp:location-info> <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> <gs:base> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList> 42.556844 -73.248157 36.6 <!--A--> 42.656844 -73.248157 36.6 <!--B--> 42.656844 -73.348157 36.6 <!--C--> 42.556844 -73.348157 36.6 <!--D--> 42.556844 -73.248157 36.6 <!--A--> </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gs:base> <gs:height uom="urn:ogc:def:uom:EPSG::9001"> 2.4 </gs:height> </gs:Prism> </gp:location-info> <gp:usage-rules/> <gp:method>Wiremap</gp:method> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> </tuple> </presence>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：GP = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10" のxmlns：GML = "http://www.opengis.net / GML」のxmlns：GS = "http://www.opengis.net/pidflo/1.0" エンティティ= "PRES：mike@someprism.example.com"> <タプルID = "プリズム"> <状態> <GP： geopriv> <GP：ロケーション情報>、<GS：プリズムsrsName = "壷：OGC：DEF：CRS：EPSG :: 4979"> <GS：ベース> <GML：ポリゴン> <GML：外装> <GML：LinearRing> <GML：POSLIST> 42.556844 -73.248157 36.6 <！ - A - > 42.656844 -73.248157 36.6 42.656844 -73.348157 36.6 42.556844 -73.348157 36.6 < - D < - - B> <！ - - C！>！ - > 42.556844 -73.248157 36.6 < - A - > </ GML：！POSLIST> </ GML：LinearRing> </ GML：外装> </ GML：ポリゴン> </ GS：ベース> <GS：高さUOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 2.4 </ gsは：高さ> </ GS：プリズム> </ GP：ロケーション情報> <GP：利用ルール/> <GP：方法>ワイヤーマップ</ GP：方法> </ GP：geopriv> </状態> <タイムスタンプ> 2007-06-22T20：57：29Z </タイムスタンプ> </タプル> </プレゼンス>
Figure 17: PIDF-LO Containing a Prism
図17：プリズムを含むPIDF-LO
The primary security considerations relate to how location information is conveyed and used, which are outside the scope of this document. This document is intended to serve only as a set of guidelines as to which elements MUST or SHOULD be implemented by systems wishing to perform location dependent routing. The ramification of such recommendations is that they extend to devices and clients that wish to make use of such services.
主要なセキュリティ上の考慮事項は、位置情報は、この文書の範囲外である、搬送及び使用方法に関する。この文書は、要素がないと、位置依存ルーティングを実行することを望むシステムによって実装すべきとしてのみ一連のガイドラインとして役立つことを意図しています。このよう勧告の枝分かれは、彼らがそのようなサービスを利用することを希望するデバイスとクライアントに延びていることです。
The authors would like to thank the GEOPRIV working group for their discussions in the context of PIDF-LO, in particular Carl Reed, Ron Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall and Robert Sparks. Furthermore, we would like to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for her constructive comments in clarifying some aspects of the document.
著者は、PIDF-LOの文脈で彼らの議論、特にカール・リード、ロン湖、ジェームズ・ポーク、ヘニングSchulzrinneと、ジェローム・グルニエ、ロジャー・マーシャルとロバート・スパークスのためGEOPRIVワーキンググループに感謝したいと思います。さらに、我々は、ドキュメントのいくつかの側面を明確にする彼女の建設的なコメントのためのPIDF-LOとナディーヌアボットの著者としてジョン・ピーターソンに感謝したいと思います。
Thanks to Karen Navas for pointing out some omissions in the examples.
例ではいくつかの欠落を指摘してカレン・ナバスに感謝します。
[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-142r1, Version: 1.0, April 2007.
[GeoShape]トムソン、M.とC.リード、、、候補者のOpenGIS実装仕様06-142r1 "GMLは、インターネットエンジニアリングタスクフォース（IETF）で使用するためにPIDF-LO形状アプリケーションのスキーマを3.1.1" バージョン：1.0、2007年4月。
[OGC-GML3.1.1] Portele, C., Cox, S., Daisy, P., Lake, R., and A. Whiteside, "Geography Markup Language (GML) 3.1.1", OGC 03-105r1, July 2003.
[OGC-GML3.1.1] Portele、C.、コックス、S.、デイジー、P.、湖、R.、およびA.ホワイトサイド、 "地理マークアップ言語（GML）3.1.1"、OGC 03-105r1 7月2003。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]ローゼンバーグ、J.、 "プレゼンスのためのAデータモデル"、RFC 4479、2006年7月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]トムソン、M.及びJ.ウィンター、RFC 5139、2008年2月 "プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）のための改訂シビックロケーションフォーマット"。
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2から20041028]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-2から20041028、2004年10月、<のhttp： //www.w3.org/TR/2004/REC-xmlschema-2-20041028>。
[3GPP.23.032] 3rd Generation Partnership Project, "Universal Geographical Area Description (GAD)", 3GPP TS 23.032 V6.0.0, January 2005, <http://www.3gpp.org/ftp/Specs/html-info/23032.htm>.
[3GPP.23.032]第3世代パートナーシッププロジェクト、 "ユニバーサル地理的領域説明（GAD）"、3GPP TS 23.032 V6.0.0、2005年1月、<http://www.3gpp.org/ftp/Specs/html-info/23032 > .htmを。
[CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03- 105r1, November 2005.
[CRS-URN]ホワイトサイド、A.、 "GML 3.1.1共通のCRSプロファイル"、OGC 03- 105r1、2005年11月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinneと、H.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[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月。
Authors' Addresses
著者のアドレス
James Winterbottom Andrew Corporation Wollongong NSW Australia
ジェームズ・ウィンターボトムアンドリュー・コーポレーションウロンゴンNSWオーストラリア
EMail: james.winterbottom@andrew.com
メールアドレス：james.winterbottom@andrew.com
Martin Thomson Andrew Corporation Wollongong NSW Australia
マーティン・トムソンアンドリュー・コーポレーションウロンゴンNSWオーストラリア
EMail: martin.thomson@andrew.com
メールアドレス：martin.thomson@andrew.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at