One document matched: draft-ietf-ecrit-specifying-holes-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY I-D.ietf-ecrit-lost-sync PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost-sync.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="bcp" ipr="full3978" docName="draft-ietf-ecrit-specifying-holes-01.txt">
<front>
<title abbrev="Service Boundary Holes">Specifying Holes in LoST Service Boundaries</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<date month="October" year="2008"/>
<area>Application</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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 LoST server, is described.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The LoST protocol <xref target="RFC5222"/> describes a protocol that's primary purpose is to map service and locations to destination addresses.
LoST 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. This document describes how holes SHOULD be specified
in service boundaries defined using a GML encoding for the polygons and their internal elements (holes). GML polygons are based on elements defined in <xref target="ISO-19107"/>.
</t>
<t>
<figure anchor="fig1" title="Holes in a Polygon">
<artwork><![CDATA[
o--------------o
/ \
/ /\ \
/ + +-----+ \
o | Hole \ o
| | 1 / |
| +-------+ |<--- Primary Polygon
| +-------+ |
| / Hole | |
o \ 2 | o
\ +-----+ + /
\ \/ /
\ /
o--------------o
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Specifying Holes">
<t>Holes related to an exterior boundary polygon MUST adhere to the following rules:
<list style="format Rule %d: " counter="holerules">
<t>Two holes MUST NOT have more than one point of intersection. If two or more holes share a common set of boundaries then to the primary polygon
these represent a single hole in the service. 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.</t>
</list>
</t>
<t>
<figure anchor="fig2" title="Incorrect Hole Specification with Boundary Sharing">
<artwork><![CDATA[
o--------------o o--------------o
/ \ / \
/ /\ \ / /\ \
/ + +-----+ \ / + +-----+ \
o | Hole \ o o | \ o
| | 1 \ | | | One \ |
| +-+-------+ | =========> | +-+ Hole + |
| / Hole | | | / | |
o \ 2 | o o \ | o
\ +-----+ + / \ +-----+ + /
\ \/ / \ \/ /
\ / \ /
o--------------o o--------------o
Incorrect Correct
]]>
</artwork>
</figure>
</t>
<t>
<list style="format Rule %d: " counter="holerules">
<t>A hole MUST NOT have more than one point of intersection with the outer-boundary of the primary (exterior) polygon. If more than one point of intersection occurs the primary polygon
is either doesn't have a hole, it has an inlet as in <xref target="inletspec"/>, or the primary polygon SHOULD be expressed as two polygons as in <xref target="multi-intersect"/>.
</t>
</list>
</t>
<t>
<figure anchor="inletspec" title="Correct Specification of an Inlet">
<artwork><![CDATA[
+------- 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
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="multi-intersect" title="Correct Specification of Hole with Multiple Outer-Boundary Intersections">
<artwork><![CDATA[
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
1 Polgon with a 2 Polygons that map
Dividing Hole to the same service
]]>
</artwork>
</figure>
</t>
<t>Similarly, a polygon containing a hole with an island must be represented as two polygons mapping to the same service.
</t>
<t>
<list style="format Rule %d: " counter="holerules">
<t>A hole MUST be a legal polygon in accordance with the geoshape specification <xref target="geoshape"/>. There is no restriction on the number of points
that may be used to express the perimeter of the hole.</t>
</list>
</t>
</section>
<section title="GML Polygons">
<t>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 <xref target="exhex"/>.
</t>
<t>
<figure anchor="exhex" title="Hexagon and Associated GML">
<artwork><![CDATA[
B--------------C
/ \
/ \
/ \
A D
\ /
\ /
\ /
F--------------E
<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>
]]>
</artwork>
</figure>
</t>
<t>NOTE that polygon vertices in <xref target="exhex"/> are expressed using <pos> elements for clarity. The vertices can also be expressed
using a <posList> element.
</t>
</section>
<section title="Holes in GML Polygons">
<t>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 <xref target="holehex"/> is represented by the
4 points of the interior boundary specified by (w,z,y,x).
</t>
<t>
<figure anchor="holehex" title="Hexagon with Hole">
<artwork><![CDATA[
B-------------C
/ \
/ w-------------x \
/ |/////////////| \
A |/////////////| D
\ |/////////////| /
\ z-------------y /
\ /
F-------------E
<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.511 -73.222</gml:pos> <!--C-->
<gml:pos>43.511 -73.322</gml:pos> <!--B-->
<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.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:interior>
</gml:Polygon>
]]>
</artwork>
</figure>
</t>
</section>
<section title="Service Boundary Specification and Selection Algorithm">
<t>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.
</t>
<t><xref target="holehex"/> shall be 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. Further more area-A is directly represented by the
GML encoding provided in <xref target="holehex"/>. 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 <xref target="area-w"/>.
</t>
<t>
<figure anchor="area-w" title="GML for Area-w">
<artwork><![CDATA[
<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>
]]>
</artwork>
</figure>
</t>
<t>If this data were in a LoST server the data mappings may look similar to the example in <xref target="lost-services"/>.
This is an example only and does not represent actual LoST server provisioning or data transfer records. The example
XML will not complie.
</t>
<t>
<figure anchor="lost-services" title="Service Boundary Specifications">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<entry>
<name> Outer Area Police Department </name>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon 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>
<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>
</entry>
<entry>
<name> Inner Area Police Department </name>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon 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>
</entry>
]]>
</artwork>
</figure>
</t>
<t>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. The format described in this memo makes support for
this operation easy, while allowing an arbitrary number of holes in a service boundary to be specified.
</t>
<t>Each primary polygon is stored in the geospatial database and mapped to a service URN and destination URI.
Holes may be stored as polygons in a separate table and mapped to the primary polygon. When a location is
found to map to a polygon, the exceptions table can be checked to see if the primary polygon contains any coverage holes.
In general no holes will exist for a service boundary, so this check results in almost no overhead and the service mapping can be returned.
Where one or more holes are found to exist, the provided location is checked against each hole. If the location is found to exist in
one of the specified holes then the primary polygon can be discarded, and searching of the service boundary database can continue.
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document does not introduce any security issues.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no specific IANA considerations for this document.
</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Carl Reed for input provided to the list some months back and for reviewing this document.
Thanks also to Michael Haberler for suggesting that such a specification is required.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5222;
<reference anchor="geoshape">
<front>
<title abbrev="Geo-Shape">GML 3.1.1 PIDF-LO Shape Application Schema for use by the
Internet Engineering Task Force (IETF)</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
</author>
<author initials="C." surname="Reed" fullname="Carl Reed, PhD.">
<organization>Open Geospatial Consortium Inc.</organization>
</author>
<date month="April" day="10" year="2007"/>
</front>
<seriesInfo name="Candidate OpenGIS Implementation Specification"
value="06-142r1, Version: 1.0"/>
</reference>
</references>
<references title="Informative References">
&I-D.ietf-ecrit-lost-sync;
<reference anchor="ISO-19107">
<front>
<title abbrev="ISO-19107">Geographic information - Spatial Schema</title>
<author>
<organization>ISO</organization>
</author>
<date day="1" month="5" year="2003"/>
</front>
<seriesInfo name="ISO Standard"
value="19107, First Edition"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:58:10 |