Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 5964 M. Thomson
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 August 2010
Specifying Holes in Location-to-Service Translation (LoST)
Service Boundaries
Abstract
抽象
This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to-Service Translation (LoST) server, is described.
この文書では、穴は、測地サービス界に指定することができる方法を説明します。 1場所・ツー・サービス翻訳（LOST）サーバーで提供するかもしれないなどのサービスデータベース内検索ソリューションを実装する1つの手段は、記載されています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5964.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5964で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Specifying Holes ................................................3
4. GML Polygons ....................................................6
5. Holes in GML Polygons ...........................................6
6. Service Boundary Specification and Selection Algorithm ..........7
7. Security Considerations ........................................10
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
The LoST protocol [RFC5222] maps service and locations to destination addresses. A LoST server does this by provisioning boundary maps or areas against service URNs. The boundary is a polygon made up of sets of geodetic coordinates specifying an enclosed area. In some circumstances, an area enclosed by a polygon, also known as an exterior polygon, may contain exception areas, or holes, that for the same service must yield a different destination to that described by the larger area.
失われたプロトコル[RFC5222]マップサービスと宛先アドレスへの場所。失われたサーバーは、サービスのURNに対する境界マップまたは領域をプロビジョニングすることによってこれを行います。境界は、囲まれた領域を指定する測地座標の組からなる多角形です。いくつかの状況では、また、外側多角形としても知られているポリゴンによって囲まれた領域は、同じサービスのために、より大きな面積で記載されたものと異なる宛先を得なければならないことを、例外領域、又は穴を含んでいてもよいです。
This document describes a profile of Geographic Markup Language (GML) [ISO-19107] polygons that constrains their representation when used for describing service boundaries. The profile removes a number of permutations that are difficult to process. This allows for simplified implementations that are not capable of handling all potential variations allowed by GML. A fully conformant GML implementation must produce polygons that fit this profile to ensure interoperability.
この文書では、サービスの境界を記述するために使用される場合、それらの表現を制約地理マークアップ言語（GML）[ISO-19107]多角形の輪郭を記述する。プロファイルは、処理することが困難な順列の数を削除します。これは、GMLによって許容されるすべての電位変動を扱うことができない単純化された実装を可能にします。完全に準拠GMLの実装は、相互運用性を確保するために、このプロファイルに適合ポリゴンを生成しなければなりません。
o--------------o
/ \
/ /\ \
/ + +-----+ \
o | Hole \ o
| | 1 / |
| +-------+ |<--- Primary Polygon
| +-------+ |
| / Hole | |
o \ 2 | o
\ +-----+ + /
\ \/ /
\ /
o--------------o
Figure 1: Holes in a Polygon
図1：多角形の穴
This document describes a profile of GML [ISO-19107] polygons that constrains their representation when used for describing service boundaries.
このドキュメントでは、サービスの境界を記述するために使用された場合、その表現を制約GML [ISO-19107]多角形の形状を説明します。
The working group considered that the types of regions described in this memo could be represented in various ways as polygons without holes, but concluded on the recommendations here to avoid potential problems with the arbitrary division of regions and to align with existing geospatial system practices.
ワーキンググループは、このメモに記載された領域の種類は穴のない多角形のような様々な方法で表現できることが考えられるが、領域の任意の分割の潜在的な問題を回避するために、既存の地理空間システム慣行と整合するようにここに勧告に結論付けました。
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]に記載されているように解釈されます。
Holes related to an exterior boundary polygon MUST adhere to the following rules:
外部境界ポリゴンに関連した穴は、以下の規則に従う必要があります。
Rule 1: Two holes MUST NOT have more than one point of intersection.
ルール1：二つの穴は、交差点の複数のポイントを持ってはいけません。
If two or more holes overlap or share a common boundary, then these represent a single hole. The internal elements (holes) should have common boundaries removed and a single hole created irrespective of whether the excluded area is itself made up of multiple service boundaries.
二つ以上の穴が重複または共通の境界を共有する場合、これらは単一の穴を表します。内部要素（ホール）は、共通の境界を取り出し、単一の穴に関係なく除外領域は、それ自体が複数のサービス境界から構成されているか否かの作らなければなりません。
o--------------o o--------------o
/ \ / \
/ /\ \ / /\ \
/ + +-----+ \ / + +-----+ \
o | Hole \ o o | \ o
| | 1 \ | | | One \ |
| +-+-------+ | =========> | +-+ Hole + |
| / Hole | | | / | |
o \ 2 | o o \ | o
\ +-----+ + / \ +-----+ + /
\ \/ / \ \/ /
\ / \ /
o--------------o o--------------o
Incorrect Correct
正誤
Figure 2: Hole Specification with Boundary Sharing
図2：境界を共有して穴仕様
Rule 2: A polygon MUST describe a contiguous region.
ルール2：ポリゴンが連続した領域に説明しなければなりません。
If a hole overlaps with the outer boundary, or it shares part of a side with the outer boundary, then it has an inlet and it MUST be expressed without the hole.
穴は、外側境界と重なる、またはそれが外側の境界と側面の一部を共有している場合、それは入口を有しており、それが穴なしで発現されなければなりません。
+------- Inlet
|
v
o---+-----+----o o---o o----o
/ |%%%%%| \ / | | \
/ /%%%%%%| \ / / | \
/ +%%%%%%%| \ / o o \
o |%%%%%%%%\ o o | \ o
| |%%%%%%%%%\ | | | \ |
| +-+%%%%%%%%+ | ========> | o-o o |
| /%%%%%%%%| | | / | |
o \%%%%%%%%| o o \ | o
\ +-----+ + / \ o-----o o /
\ \/ / \ \/ /
\ / \ /
o--------------o o--------------o
Incorrect Correct
正誤
Figure 3: Specification of an Inlet
図3：入口の仕様
If a hole touches the outer boundary in two places, the region MUST be expressed as two separate polygons.
穴が2箇所に外側境界をタッチすると、領域は、2つの別個の多角形として表現されなければなりません。
A--q-----------B A-q q----------B
/ | | \ / | | \
/ | | \ / | | \
/ z r-----s \ / P z r-----s P \
H | \ C H o | \ o C
| | One \ | | l | \ l |
| y-x Hole t | ========> | y y-x t y |
| / | | | g / | g |
G \ | D G o \ | o D
\ / v---u / \ n / v---u n /
\ \ / / \ 1 \ / 2 /
\ \ / / \ \ / /
F-----w--------E F-----w w--------E
Incorrect Correct
正誤
Figure 4: Specification of Hole with Multiple Outer-Boundary Intersections
図4：複数の外側境界交差の穴の仕様
Similarly, a polygon that is enclosed entirely within a hole from another polygon (i.e., an "island") is a separate polygon.
同様に、他のポリゴン（すなわち、「島」）から完全に穴内に封入されたポリゴンは、別個の多角形です。
o--------------o
/ \
/ +--------------+ \
/ |%%%%%%%%%%%%%%| \
o |%%o--------o%%| o
| |%/ Island \%| |
| |%\ /%| |
| |%%o--------o%%| |
o |%%%%%%%%%%%%%%| o
\ +--------------+ /
\ /
\ /
o--------------o
Figure 5: Hole with Enclosed Polygon (Island)
図5：密閉型ポリゴンでホール（アイランド）
Rule 3: A hole MUST be formed from a legal linear ring in accordance with [geoshape], except that points are specified in a clockwise direction.
ルール3：ホールポイントが時計方向に指定されていることを除いて、[geoshape]に従って法的線形リングから形成されなければなりません。
Holes are specified in a clockwise direction so that the upward normal is opposed to the upward normal of the exterior boundary of the polygon. Note that [geoshape] stipulates that exterior boundaries are specified in counterclockwise order.
上方通常ポリゴンの外側の境界線の上方に正常に対向するようにホールが時計回りの方向に規定されています。 [geoshape]外装境界が反時計回りに順番に指定されていることを規定していることに注意してください。
There is no restriction on the number of points that are used to express the perimeter of either exterior or interior boundaries.
外部又は内部のいずれかの境界の周囲を発現させるために使用されるポイントの数に制限はありません。
The GML encoding of a polygon defines a enclosed exterior boundary, with the first and last points of boundary being the same. Consider the example in Figure 6.
ポリゴンのGML符号化は同じである境界の最初と最後の点で囲まれた外側の境界を定義します。図6の例を考えます。
F--------------E
/ \
/ \
/ \
A D
\ /
\ /
\ /
B--------------C
<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> <!--B--> <gml:pos>43.111 -73.222</gml:pos> <!--C--> <gml:pos>43.311 -73.122</gml:pos> <!--D--> <gml:pos>43.411 -73.222</gml:pos> <!--E--> <gml:pos>43.411 -73.322</gml:pos> <!--F--> <gml:pos>43.311 -73.422</gml:pos> <!--A--> </gml:LinearRing> </gml:exterior> </gml:Polygon>
<GML：ポリゴンsrsNameは= "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：外装> <GML：リニアリング> <GML：POS> 43311 73422 </ GML：POS> <！ - - > <GML：POS> 43111 73 322 </ GML：POS> < - B - > <GML：POS> 43111 73 222 </ GML：POS> < - C - > <GML！ POS> 43311 73 122 </ GML：POS> < - D - > <GML：POS> 43411 73 222 </ GML：POS> < - E - > <GML：POS> 43411 73322 < / GML：POS> < - F - > <GML：！POS> 43311 73 422 </ GML：！POS> < - A - > </ GML：リニアリング> </ GML：外装> </ GML ：ポリゴン>
Figure 6: Hexagon and Associated GML
図6：六角と関連GML
Note that polygon vertices in Figure 6 are expressed using <pos> elements for clarity. The vertices can also be expressed using a <posList> element.
図6におけるポリゴンの頂点を明確にするために<POS>要素を用いて表現されることに留意されたいです。頂点はまた、<POSLIST>要素を用いて表現することができます。
A hole is specified in the polygon by defining an interior boundary. The points defining the internal boundary define the area represented by the hole in the primary (exterior) polygon. The shaded area in Figure 7 is represented by the 4 points of the interior boundary specified by (w,z,y,x).
穴は、内部境界を定義することにより、ポリゴンで指定されます。内部境界を規定する点は、主（外部）多角形の穴によって示される領域を画定します。図7の斜線部は、（X、Z、Y、W）で指定された内部境界の4点で表されます。
F-------------E
/ \
/ w-------------x \
/ |/////////////| \
A |/////////////| D
\ |/////////////| /
\ z-------------y /
\ /
B-------------C
<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> <!--B--> <gml:pos>43.111 -73.222</gml:pos> <!--C--> <gml:pos>43.311 -73.122</gml:pos> <!--D--> <gml:pos>43.511 -73.222</gml:pos> <!--E--> <gml:pos>43.511 -73.322</gml:pos> <!--F--> <gml:pos>43.311 -73.422</gml:pos> <!--A--> </gml:LinearRing> </gml:exterior> <gml:interior> <gml:LinearRing> <gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.411 -73.222</gml:pos> <!--x--> <gml:pos>43.211 -73.222</gml:pos> <!--y--> <gml:pos>43.211 -73.322</gml:pos> <!--z--> <gml:pos>43.411 -73.322</gml:pos> <!--w--> </gml:LinearRing> </gml:interior> </gml:Polygon>
<GML：ポリゴンsrsNameは= "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：外装> <GML：リニアリング> <GML：POS> 43311 73422 </ GML：POS> <！ - - > <GML：POS> 43111 73 322 </ GML：POS> < - B - > <GML：POS> 43111 73 222 </ GML：POS> < - C - > <GML！ POS> 43311 73 122 </ GML：POS> < - D - > <GML：POS> 43511 73 222 </ GML：POS> < - E - > <GML：POS> 43511 73322 < / GML：！POS> < - F - > <GML：POS> 43311 73 422 </ GML：！POS> < - A - > </ GML：リニアリング> </ GML：外装> <GML：インテリア> <GML：リニアリング> <GML：POS> 43411 73 322 </ GML：！POS> < - ワット - > <GML：POS> 43411 73 222 </ GML：POS> < - x--！ > <GML：POS> 43211 73 222 </ GML：POS> < - Y - > <GML：POS> 43211 73 322 </ GML：POS> < - Z - > <GML：POS> 43411 73322：<！ - ワット - > </ GML POS> </ GML：リニアリング> </ GML：インテリア> </ GML：ポリゴン>
Figure 7: Hexagon with Hole
図7：穴付き六角
A service boundary is represented by a polygon that may have many vertices. The enclosed area of the polygon represents the area in which a service, expressed as a service URN, maps to a single URI.
サービス境界は、多くの頂点を有することができるポリゴンで表現されます。ポリゴンの囲まれた領域は、サービスは、サービスURNとして表現される領域を表す単一のURIにマッピングします。
Figure 7 is used to illustrate two service boundaries. The first service boundary A->F shall be referred to as area-A, and the second service boundary w->z shall be referred to as area-w. Furthermore, area-A is directly represented by the GML encoding provided in Figure 7. Area-w is represented as a hole in area-A by the interior boundary. Since area-w is also a service boundary, a separate polygon describing this area is also required and is shown in Figure 8 (note the reversal of the vertices).
図7は、2つのサービスの境界を示すために使用されています。最初のサービス境界A-> Fは、エリアAと呼ばれ、第2のサービス境界W-なければならない> Zが領域-Wと呼ぶことにします。また、領域Aは、直接図7エリア-Wに設けられたGML符号化は内部境界によってエリアAにおける穴として表されるで表されます。エリアwが、サービス境界であるので、この領域を記述する別個の多角形はまた、必要とされると（頂点の逆転に注意）図8に示されています。
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:pos>43.411 -73.322</gml:pos> <!--w--> <gml:pos>43.211 -73.322</gml:pos> <!--z--> <gml:pos>43.211 -73.222</gml:pos> <!--y--> <gml:pos>43.411 -73.222</gml:pos> <!--x--> <gml:pos>43.411 -73.322</gml:pos> <!--w--> </gml:LinearRing> </gml:exterior> </gml:Polygon>
<GML：ポリゴンsrsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：外装> <GML：リニアリング> <GML：POS> 43411 73 322 </ GML：POS> < - ワット！ - > <GML：POS> 43211 73 322 </ GML：POS> < - Z - > <GML：POS> 43211 73 222 </ GML：POS> < - Y - > <GML！ POS> 43411 73 222 </ GML：！POS> < - X - > <GML：POS> 43411 73 322 </ GML：！POS> < - ワット - > </ GML：リニアリング> </ GML ：外装> </ GML：ポリゴン>
Figure 8: GML for Area-w
図8：エリア-WのGML
Service mappings for these boundaries might be provided by a LoST server in the form shown in Figure 9.
これらの境界のサービスマッピングは、図9に示した形で失われたサーバによって提供されることがあります。
<mapping xmlns="urn:ietf:params:xml:ns:lost1" expires="2010-12-25T09:44:33Z" lastUpdated="2010-03-08T03:48:22Z" source="authoritative.foo.example" sourceId="7e3f40b098c711dbb606011111111111"> <displayName xml:lang="en">Outer Area Police</displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <gml:Polygon xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:pos>43.311 -73.422</gml:pos> <gml:pos>43.111 -73.322</gml:pos> <gml:pos>43.111 -73.222</gml:pos> <gml:pos>43.311 -73.122</gml:pos> <gml:pos>43.511 -73.222</gml:pos> <gml:pos>43.511 -73.322</gml:pos> <gml:pos>43.311 -73.422</gml:pos> </gml:LinearRing> </gml:exterior> <!-- this is the service boundary hole --> <gml:interior> <gml:LinearRing> <gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.211 -73.322</gml:pos> <gml:pos>43.211 -73.222</gml:pos>
<マッピングのxmlns = "URN：IETF：paramsは：XML：NS：lost1" はLastUpdated = "2010-03-08T03：48：22Z" ソース=「authoritative.foo =の "：44 33Z 2010-12-25T09" 満了します。例えば、 "ソースID =" 7e3f40b098c711dbb606011111111111 "> <DisplayNameにXML：LANG =" ">外側領域警察</表示名> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロフィール="「測地-2D> < GML：ポリゴンのxmlns：GML = "http://www.opengis.net/gml" srsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：外装> <GML：リニアリング> <GML： POS> 43311 73 422 </ GML：POS> <GML：POS> 43111 73 322 </ GML：POS> <GML：POS> 43111 73 222 </ GML：POS> <GML：POS> 43311 73 122 </ GML ：POS> <GML：POS> 43511 73 222 </ GML：POS> <GML：POS> 43511 73 322 </ GML：POS> <GML：POS> 43311 73 422 </ GML：POS> </ GML：リニアリング> </ GML：外装> < - > <GML - これは、サービスの境界穴です！インテリア> <GML：リニアリング> <GML：POS> 43411 73322 </ GML：POS> <GML：POS> 43211 73322 </ GML：POS> <GML：POS> 43211 73 222 </ GML：POS>
<gml:pos>43.411 -73.222</gml:pos> <gml:pos>43.411 -73.322</gml:pos> </gml:LinearRing> </gml:interior> </gml:Polygon> </serviceBoundary> <uri>sip:area-A-pd@example.com</uri> <uri>xmpp:area-A-pd@example.com</uri> <serviceNumber>000</serviceNumber> </mapping>
<GML：POS> 43.411 -73.222 </ GML：POS> <GML：POS> 43.411 -73.322 </ GML：POS> </ GML：LinearRing> </ GML：内部> </ GML：ポリゴン> </ serviceBoundary> <URI> SIP：area-A-pd@example.com </ URI> <URI> XMPP：area-A-pd@example.com </ URI> <serviceNumber> 000 </ serviceNumber> </マッピング>
<mapping xmlns="urn:ietf:params:xml:ns:lost1" expires="2010-12-25T09:44:33Z" lastUpdated="2010-03-08T03:48:22Z" source="authoritative.foo.example" sourceId="7e3f40b098c711dbb606011111111111"> <displayName xml:lang="en">Inner Area Police</displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <gml:Polygon xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4326"> <gml:exterior> <gml:LinearRing> <gml:pos>43.411 -73.322</gml:pos> <gml:pos>43.211 -73.322</gml:pos> <gml:pos>43.211 -73.222</gml:pos> <gml:pos>43.411 -73.222</gml:pos> <gml:pos>43.411 -73.322</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> </serviceBoundary> <uri>sip:area-w-pd@example.com</uri> <uri>xmpp:area-w-pd@example.com</uri> <serviceNumber>000</serviceNumber> </mapping>
<マッピングのxmlns = "URN：IETF：paramsは：XML：NS：lost1は" lastUpdated = "2010-03-08T03：48：22Z" ソース= "authoritative.foo =の "：44 33Z 2010-12-25T09" 満了します。たとえば、」ソースID = "7e3f40b098c711dbb606011111111111"> <のdisplayNameのxml：LANG = "EN">内側の領域警察</のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル= "測地-2D"> < GML：ポリゴンのxmlns：GML = "http://www.opengis.net/gml" srsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：外装> <GML：LinearRing> <GML： POS> 43.411 -73.322 </ GML：POS> <GML：POS> 43.211 -73.322 </ GML：POS> <GML：POS> 43.211 -73.222 </ GML：POS> <GML：POS> 43.411 -73.222 </ GML ：POS> <GML：POS> 43.411 -73.322 </ GML：POS> </ GML：LinearRing> </ GML：外装> </ GML：ポリゴン> </ serviceBoundary> <URI> SIP：エリア-W-PD @ example.com </ URI> <URI> XMPP：area-w-pd@example.com </ URI> <serviceNumber> 000 </ serviceNumber> </マッピング>
Figure 9: Service Boundary Specifications
図9：サービスの境界の仕様
It is considered likely that LoST servers will need to provide responses sufficiently quickly to allow real-time queries to be performed as part of an emergency call routing flow. It is for this reason that databases supporting native geospatial query techniques are desirable and that service boundary specifications that are easily mapped to internal data structures are preferred. Using interior boundaries makes support for this operation easy, while allowing an arbitrary number of holes in a service boundary to be specified.
サーバがリアルタイムクエリは、緊急コールルーティングの流れの一部として実行できるようにするために十分に迅速な応答を提供する必要があります失われた可能性が高いと考えられています。これは、ネイティブの地理空間クエリ技術が望まれていると簡単に内部データ構造にマッピングされ、そのサービスの境界の仕様が優先されているサポートするデータベースはこのためです。サービス境界の穴の任意の数を指定することを可能にしながら内部境界を使用することで、簡単にこの操作のサポートを行います。
Each polygon is stored in the geospatial database and mapped to a service URN and destination URI. Many geospatial databases natively support polygons with interior exclusions. Without native support, interior boundaries can be stored against the polygon and can checked separately. A location falls within the area described by a polygon if it is within the exterior boundary and not within any interior boundary.
各ポリゴンは、地理空間データベースに格納され、サービスURNと宛先URIにマッピングされます。多くの地理空間データベースは、ネイティブインテリア除外を用いて多角形をサポートしています。ネイティブサポートがなければ、内部境界はポリゴンに対して保存することができ、個別に確認することができます。それは外側の境界内になく、任意の内部境界内にある場合位置は、ポリゴンによって記述される領域内に入ります。
In the above example, if a location falls within the interior boundary, it maps to the "Inner Area Police" service; likewise, if a location falls within the exterior boundary, but not within the interior boundary, it maps to the "Outer Area Police" service.
場所は内部境界内にある場合は、上記の例では、それは「内側の領域警察」サービスにマップ。場所は外部境界内ではなく、内部の境界内にある場合も同様に、それは「外部領域警察」サービスに対応します。
Constraining the form of a polygon representation as described in this document does not introduce new security considerations.
この文書に記載されたポリゴン表現の形式を制約する新しいセキュリティ上の考慮事項を導入しません。
Thanks to Carl Reed for input provided to the list some months back and for reviewing this document. Thanks to Michael Haberler for suggesting that such a specification is required. Thanks to Avery Penniston for review and feedback.
数ヶ月戻っリストに与えられた入力のため、この文書を検討するためのカール・リードに感謝します。そのような仕様が必要とされることを示唆しているため、マイケルHaberlerに感謝します。レビューとフィードバックのためのAvery Pennistonに感謝します。
[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月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、RFC 5222、2008年8月。
[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月。
[ISO-19107] ISO, "Geographic information - Spatial Schema", ISO Standard 19107, First Edition, May 2003.
[ISO-19107] ISO、 "地理情報 - 空間スキーマ"、ISO規格19107、初版、2003年5月。
Authors' Addresses
著者のアドレス
James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
ジェームズ・ウィンターボトムアンドリュー・コーポレーションアンドリュービル（39）ウーロンゴン大学キャンパスNorthfieldsアベニューウロンゴン、NSW 2522 AU
EMail: james.winterbottom@andrew.com
メールアドレス：james.winterbottom@andrew.com
Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
マーティン・トムソンアンドリュー・コーポレーションアンドリュービル（39）ウーロンゴン大学キャンパスNorthfieldsアベニューウロンゴン、NSW 2522 AU
EMail: martin.thomson@andrew.com
メールアドレス：martin.thomson@andrew.com