[要約] 要約：RFC 5491は、GEOPRIVプレゼンス情報データ形式の位置オブジェクト（PIDF-LO）の使用に関する明確化、考慮事項、および推奨事項を提供しています。 目的：このRFCの目的は、PIDF-LOの使用に関する混乱を解消し、一貫性と相互運用性を確保するためのガイドラインを提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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の使用を禁止することを試みません。このドキュメントは、1つの場所を明確に伝えることが重要な場合、存在ドキュメントを構築するための特定の一連のガイドラインを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The 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形式は、<tuple>、<device>、および<パーソン>要素の数の数の数を提供します。これらの各要素には、子供として複数の<geopriv>要素を含む可能性のある単一の<status>要素が含まれています。各<geopriv>要素には、少なくとも次の2つの子要素が含まれている必要があります。<location-info>要素と<usage-rules>要素。位置情報を含む1つ以上の要素は、<location-info>要素内に含まれています。
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>
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：a <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：個別の場所を複数の方法で一意に説明できる場合、各場所の説明は別の<tuple>、<device>、または<serson>要素に存在する必要があります。タプルごとに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>要素を提供することは、場所が同じ場所を参照するか、異なる要素タイプに入れられる場合にのみ行う必要があります。たとえば、<tuple>の1つの場所、<device>要素の2番目の場所、<パーソン>要素の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.
これは、ターゲットの位置が一連の異なる手法を使用して決定される場合、またはターゲットが彼女の位置とPCの位置を表現したい場合に発生する可能性があります。一般に、理にかなっていない限り、複数の場所をドキュメントに入れないでください。
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：可能であれば、単一の<location-info>要素で複数のロケーションチャンクを提供することを避ける必要があります。ルール＃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：単一の<location-info>要素で複数のロケーションチャンクを提供する場合、場所は同時に共通のソースと同じ場所決定方法によって提供される必要があります。
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：単一の<location-info>要素で複数の位置チャンクを提供することは、同じ場所を参照する複合場所を表すためにのみ使用する必要があります。
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：複合位置が単一の<location-info>要素で提供される場合、最初に粗い位置情報を提供する必要があります。
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>要素が含まれている場合、解釈の優先順位は、場所を含むドキュメントの最初の<device>要素に与えられます。ドキュメントに場所を含む<device>要素がない場合、場所を含む最初の<tuple>要素の優先度が与えられます。タプルに含まれる場所は、最後の手段としてのみ使用する必要があります。
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.
ルール＃9：複数のPIDFドキュメントを一緒に送信または受信できる場合、たとえばマルチパートMIMEボディで、現在の位置情報が受信者に必要である場合、ドキュメントの選択はドキュメントの順序に基づいて、最初のドキュメントを最初に考慮してください。。
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.
ジェーンは、大きなショッピングモールの1階にあるコーヒーショップにいます。ジェーンはラップトップをオンにし、コーヒーショップのWiFiホットスポットに接続します。ジェーンは、[RFC4776]で定義されているDHCP市民メカニズムを使用して、現在の場所の完全な市民住所を取得します。ロケーションオブジェクトは、単一のPIDFドキュメントで構成されており、単一の<tuple>または<device>要素、単一の<status>要素、単一の<geopriv>要素、および<location-infoに存在する単一の場所チャンクを備えています。>要素。このドキュメントは明確であり、ネットワークを介して送信された場合にノードを受信することにより、一貫して解釈する必要があります。
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>
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.
ロレインは、通常シドニーに住んでいるため、ラップトップに保管されている事前に定義された市民の場所を持っています。住所はシドニーに拠点を置くアパート用です。ロレインはサニーサンフランシスコを訪れることにしました、そして、彼女がそこに着くと、彼女はラップトップを差し込んで電話をかけます。Loraineのラップトップは、サンフランシスコの訪問されたネットワークから新しい場所を受け取ります。このシステムは、既存の場所と新しい場所が同じ場所を説明することを確信できないため、Loraineのコンピューターは新しいPIDF-LOを生成し、これを使用してLoraineの場所を表します。Loraineのコンピューターが既存のPIDFロケーションドキュメントに新しい場所を追加する場合（ルール＃3を破壊）、Loraineのシステムを提供する場所を提供する場所の受信者によって正しい情報がまだ解釈される場合があります。この場合、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の場所を公園として示す<device>要素と、ヴァネッサが彼女のオフィスにいると言っている<パーソン>要素があります。
<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">
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>
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.
RFC 4119 [RFC4119]で提供される測地例は、<gml：coordinates>要素を使用する<gml：location>要素を使用して示されています。この表現にはいくつかの欠点があります。第一に、GML（3.1以降）の後のバージョンでは廃止されているため、新しいアプリケーションに使用することはできません。第二に、座標型の形式は不透明であるため、同じ測地位置をさまざまな方法で表現できるため、一貫した結果を確保するために解析して解釈することは困難です。PIDF-LO Geodetic Shapes仕様[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.
現在、Cellular Mobile Worldは、緊急事態およびその他の位置ベースのアプリケーションのための測地ベースの位置情報を広範囲に使用しています。一般に、これらの場所は、ポイント（2つまたは3つの次元のいずれか）と、ポイント周辺の不確実性の領域または量として表現されます。理論的には、エリアまたはボリュームは、ユーザーが発見される可能性が比較的高いカバレッジを表し、ポイントは面積またはボリュームの重心を定義する便利な手段です。実際には、ほとんどのシステムはポイントを絶対値として使用し、不確実性を無視します。簡単にするためにこの方法でシステムが実装されているかどうかを判断することは困難であり、不確実性が将来より重要な役割を果たすかどうかを予測することはさらに困難です。重要な決定は、不確実性領域を指定する必要があるかどうかです。
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]は、Open Mobile Alliance（OMA）モバイルロケーションプロトコル（MLP）など、他のアプリケーションやプロトコルで使用される形状定義に簡単に翻訳される8つの形状タイプを定義します。完全性については、[Geoshape]で定義されている形状を以下に示します。
o Point (2d and 3d)
o ポイント（2Dおよび3D）
o Polygon (2d)
o ポリゴン（2d）
o Circle (2d)
o サークル（2d）
o Ellipse (2d)
o 楕円（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）、および規則の標準セットについても説明しています。World Geodetic System 1984（WGS84）[WGS84]の使用参照システムと欧州石油調査グループ（EPSG）コード4326の使用（urn urn：ogc：def：crs：epsg :: 4326、[[Crs-urn]）2次元（2D）形状表現およびEPSG 4979（urn urn：ogc：def：crs：epsg :: 4979で識別されるように）3次元（3d）体積表現の場合。距離と高さは、EPSG 9001を使用してメーターで表されます（urn urn：ogc：def：uom：epsg :: 9001で識別されます）。角度測定は、度またはラジアンのいずれかを使用する必要があります。程度の測定値は、urn urn：ogc：def：uom：epsg :: 9102によって特定されなければなりません。ラジアンの測定はurnによって識別されなければなりません：ogc：def：uom：epsg :: 9101。ベアリングを表す角度は、磁気北ではなく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は、サブエレメントについて尊重または変更してはなりません。これらのCRSSの寸法の数がわかっているため、srsdimension属性を省略する必要があります。上記のURN表記のみを使用してCRSを指定する必要があります。実装では、ユーザー定義の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]で定義された「double」の語彙表現を使用して表されます。先10進ポイントを過ぎている主要なゼロと後続のゼロは重要ではありません。たとえば、「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）で定義されているプロトコル（[3GPP.23.032]を参照）とOMAのような他の位置輸送プロトコルとの相互操作を可能にするために選択されます。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 kmに制限する必要があります。この制限に関する詳細情報は、[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.
3次元座標を使用してポリゴンで指定されたポイントは、すべて同じ高度を持っている必要があります。
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>
Figure 4: PIDF-LO Containing a Two-Dimensional Point
図4：2次元ポイントを含む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>
Figure 5: PIDF-LO Containing a Three-Dimensional Point
図5：3次元ポイントを含む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.
ポリゴンの形状のタイプは、建物のアウトラインまたはカバレッジエリアを表すために使用できます。ポリゴンの最初と最後のポイントは同じでなければなりません。たとえば、図6の六角形を頂点A、B、C、D、E、およびFを見ると、結果のポリゴンは7ポイントで定義され、最初と最後のポイントは両方ともポイント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>
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要素よりもポリゴン頂点の座標のよりコンパクトな表現を提供するポスリストをサポートしています。よりコンパクトなフォームを図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>
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.
円形領域は、2次元CRSSの座標に使用され、ポイントに関する不確実性を説明します。定義は、GML、GML：CircleByCenterPointの1次元ジオメトリに基づいています。円形領域の中心点は、2次元CRSを使用して指定されています。3次元では、この表現を使用して円の方向を正しく指定することはできません。3次元で指定されている不確実性のあるポイントは、球の形状タイプを使用する必要があります。
<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>
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.
楕円形の領域は、2次元空間の楕円を説明しています。楕円は、中心点、その半主要な軸と半ミノール軸の長さ、およびセミメジャー軸の向きによって記述されています。円形領域（円）と同様に、楕円を2次元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>
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：Semimiminoraxis要素は、それぞれ半明細軸と半ミノール軸の長さです。GS：方向要素とは、半長軸がCRSの最初の軸から2番目の軸に向かって回転する角度です。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.
ARCバンドの形状タイプは、一般的に、タイミングの前進またはコードオフセットシーケンスが携帯電話とアクセスポイント間の距離を補正するために使用されるワイヤレスシステムで生成されます。アークバンドは、中心点から発せられる2つの半径と、アークの開始角と開口角を表す2つの角度として表されます。セルラー環境では、中心点は名目上、セルタワーの位置であり、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ベースのネットワークの場合、これにより、ポールはセルタワーから約3,594メートルから4,148メートルの間に配置され、内側および外側の半径値を提供します。開始角度が北から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>
Figure 12: PIDF-LO Containing an Arc Band
図12：ARCバンドを含む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.
ARCバンドで作成する重要なメモは、形状の定義で使用される中心点が得られた囲まれた領域に含まれておらず、そのターゲットはARCバンドの定義された領域のどこにでもあることです。
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次元の円と同じ情報を提供するボリュームです。球体は、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>
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次元で指定された中心点の周りに構築され、互いに垂直な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>
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>
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、特にカール・リード、ロン・レイク、ジェームズ・ポーク、ヘニング・シュルツリン、ジェローム・グレニエ、ロジャー・マーシャル、ロバート・スパークスの文脈での議論について、Geoprivワーキンググループに感謝したいと思います。さらに、ドキュメントのいくつかの側面を明確にするための建設的なコメントについて、PIDF-LOとNadine Abbottの著者としてJon Petersonに感謝します。
Thanks to Karen Navas for pointing out some omissions in the examples.
例でいくつかの省略を指摘してくれたKaren Navasに感謝します。
[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] Thomson、M。and C. Reed、「GML 3.1.1 Internet Engineering Task Force（IETF）が使用するPIDF-LO形状アプリケーションスキーマ」、候補OpenGIS実装仕様06-142R1、バージョン：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.、Cox、S.、Daisy、P.、Lake、R。、およびA. Whiteside、「Geography Markup Language（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、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] Thomson、M。and J. Winterbottom、「存在情報形式の市民ロケーション形式の改訂データ形式の場所オブジェクト（PIDF-LO）」、RFC 5139、2008年2月。
[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] Biron、P。およびA. Malhotra、「XML Schema Part 2：DataTypes Second Edition」、World Wide Webコンソーシアムの推奨REC-XMLSCHEMA-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.org/ftp/specs/html-info/230322322322323232.htm>。
[CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03- 105r1, November 2005.
[CRS-urn] Whiteside、A。、「GML 3.1.1 Common CRSSプロファイル」、OGC 03- 105R1、2005年11月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J.、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Dynamic Host Configuration Protocol（DHCPV4およびDHCPV6）の市民アドレス構成情報のオプション」、RFC 4776、2006年11月。
[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
Martin Thomson Andrew Corporation Wollongong NSW Australia
マーティン・トムソン・アンドリュー・コーポレーション・ウロン・ノン・サウス・オーストラリア
EMail: martin.thomson@andrew.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at