summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5964.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5964.txt')
-rw-r--r--doc/rfc/rfc5964.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5964.txt b/doc/rfc/rfc5964.txt
new file mode 100644
index 0000000..bf03d9e
--- /dev/null
+++ b/doc/rfc/rfc5964.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 1]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+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
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 2]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ o--------------o
+ / \
+ / /\ \
+ / + +-----+ \
+ o | Hole \ o
+ | | 1 / |
+ | +-------+ |<--- Primary Polygon
+ | +-------+ |
+ | / Hole | |
+ o \ 2 | o
+ \ +-----+ + /
+ \ \/ /
+ \ /
+ o--------------o
+
+ Figure 1: Holes in a Polygon
+
+ This document describes a profile of GML [ISO-19107] polygons that
+ constrains their representation when used for describing service
+ boundaries.
+
+ 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.
+
+2. Terminology
+
+ 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].
+
+3. Specifying Holes
+
+ 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.
+
+ 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.
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 3]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ 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
+
+ Rule 2: A polygon MUST describe a contiguous region.
+
+ 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
+
+ If a hole touches the outer boundary in two places, the region MUST
+ be expressed as two separate polygons.
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 4]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ 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
+
+ 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)
+
+ 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.
+
+ 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.
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 5]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ There is no restriction on the number of points that are used to
+ express the perimeter of either exterior or interior boundaries.
+
+4. GML Polygons
+
+ 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.
+
+ 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>
+
+ Figure 6: Hexagon and Associated 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.
+
+5. Holes in GML Polygons
+
+ 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).
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 6]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ 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>
+
+ Figure 7: Hexagon with Hole
+
+6. Service Boundary Specification and Selection Algorithm
+
+ 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.
+
+ 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
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 7]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ 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).
+
+ <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>
+
+ Figure 8: GML for Area-w
+
+ Service mappings for these boundaries might be provided by a LoST
+ server in the form shown in Figure 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>
+
+
+
+Winterbottom & Thomson Standards Track [Page 8]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ <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>
+
+ <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>
+
+ Figure 9: Service Boundary Specifications
+
+ 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.
+
+
+
+Winterbottom & Thomson Standards Track [Page 9]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+ 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.
+
+ 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.
+
+7. Security Considerations
+
+ Constraining the form of a polygon representation as described in
+ this document does not introduce new security considerations.
+
+8. Acknowledgements
+
+ 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.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
+ Tschofenig, "LoST: A Location-to-Service Translation
+ Protocol", RFC 5222, August 2008.
+
+ [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.
+
+9.2. Informative References
+
+ [ISO-19107] ISO, "Geographic information - Spatial Schema", ISO
+ Standard 19107, First Edition, May 2003.
+
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 10]
+
+RFC 5964 Service Boundary Holes August 2010
+
+
+Authors' Addresses
+
+ James Winterbottom
+ Andrew Corporation
+ Andrew Building (39)
+ Wollongong University Campus
+ Northfields Avenue
+ Wollongong, NSW 2522
+ AU
+
+ EMail: james.winterbottom@andrew.com
+
+
+ Martin Thomson
+ Andrew Corporation
+ Andrew Building (39)
+ Wollongong University Campus
+ Northfields Avenue
+ Wollongong, NSW 2522
+ AU
+
+ EMail: martin.thomson@andrew.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom & Thomson Standards Track [Page 11]
+