idnits 2.17.1
draft-ietf-ecrit-specifying-holes-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 187 has weird spacing: '...x Hole t ...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 24, 2010) is 5147 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'I-D.ietf-ecrit-lost-sync' is defined on line 467, but
no explicit reference was found in the text
== Outdated reference: A later version (-18) exists of
draft-ietf-ecrit-lost-sync-09
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ECRIT J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: BCP Andrew Corporation
5 Expires: September 25, 2010 March 24, 2010
7 Specifying Holes in LoST Service Boundaries
8 draft-ietf-ecrit-specifying-holes-03
10 Abstract
12 This document describes how holes can be specified in geodetic
13 service boundaries. One means of implementing a search solution in a
14 service database, such as one might provide with a LoST server, is
15 described.
17 Status of this Memo
19 This Internet-Draft is submitted to IETF in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on September 25, 2010.
40 Copyright Notice
42 Copyright (c) 2010 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 3. Specifying Holes . . . . . . . . . . . . . . . . . . . . . . . 5
60 4. GML Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 8
61 5. Holes in GML Polygons . . . . . . . . . . . . . . . . . . . . 9
62 6. Service Boundary Specification and Selection Algorithm . . . . 10
63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
67 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
68 10.2. Informative References . . . . . . . . . . . . . . . . . 16
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
71 1. Introduction
73 The LoST protocol [RFC5222] maps service and locations to destination
74 addresses. A LoST server does this by provisioning boundary maps or
75 areas against service URNs. The boundary is a polygon made up of
76 sets of geodetic coordinates specifying an enclosed area. In some
77 circumstances an area enclosed by a polygon, also known as an
78 exterior polygon, may contain exception areas, or holes, that for the
79 same service must yield a different destination to that described by
80 the larger area.
82 This document describes the RECOMMENDED approach to specifying holes
83 in service boundaries defined using a GML encoding for the polygons
84 and their internal elements (holes).
86 o--------------o
87 / \
88 / /\ \
89 / + +-----+ \
90 o | Hole \ o
91 | | 1 / |
92 | +-------+ |<--- Primary Polygon
93 | +-------+ |
94 | / Hole | |
95 o \ 2 | o
96 \ +-----+ + /
97 \ \/ /
98 \ /
99 o--------------o
101 Figure 1: Holes in a Polygon
103 This document describes a profile of Geographic Markup Language (GML)
104 [ISO-19107] polygons that constrains their representation when used
105 for describing service boundaries.
107 The working group considered that the types of regions described in
108 this memo could be represented in various ways as polygons without
109 holes, but concluded on the recommendations here to avoid potential
110 problems with the arbitrary division of regions and to align with
111 existing geospatial system practices.
113 2. Terminology
115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
117 document are to be interpreted as described in [RFC2119].
119 3. Specifying Holes
121 Holes related to an exterior boundary polygon MUST adhere to the
122 following rules:
124 Rule 1: Two holes MUST NOT have more than one point of
125 intersection.
127 If two or more holes overlap or share a common boundary then these
128 represent a single hole. The internal elements (holes) should have
129 common boundaries removed and a single hole created irrespective of
130 whether the excluded area is itself made up of multiple service
131 boundaries.
133 o--------------o o--------------o
134 / \ / \
135 / /\ \ / /\ \
136 / + +-----+ \ / + +-----+ \
137 o | Hole \ o o | \ o
138 | | 1 \ | | | One \ |
139 | +-+-------+ | =========> | +-+ Hole + |
140 | / Hole | | | / | |
141 o \ 2 | o o \ | o
142 \ +-----+ + / \ +-----+ + /
143 \ \/ / \ \/ /
144 \ / \ /
145 o--------------o o--------------o
147 Incorrect Correct
149 Figure 2: Hole Specification with Boundary Sharing
151 Rule 2: A polygon MUST describe a contiguous region.
153 If a hole overlaps with the outer boundary, or it shares part of a
154 side with the outer boundary, then it has an inlet and it MUST be
155 expressed without the hole.
157 +------- Inlet
158 |
159 v
160 o---+-----+----o o---o o----o
161 / |%%%%%| \ / | | \
162 / /%%%%%%| \ / / | \
163 / +%%%%%%%| \ / o o \
164 o |%%%%%%%%\ o o | \ o
165 | |%%%%%%%%%\ | | | \ |
166 | +-+%%%%%%%%+ | ========> | o-o o |
167 | /%%%%%%%%| | | / | |
168 o \%%%%%%%%| o o \ | o
169 \ +-----+ + / \ o-----o o /
170 \ \/ / \ \/ /
171 \ / \ /
172 o--------------o o--------------o
174 Incorrect Correct
176 Figure 3: Specification of an Inlet
178 If a hole touches the outer boundary in two places, the region MUST
179 be expressed as two separate polygons.
181 A--q-----------B A-q q----------B
182 / | | \ / | | \
183 / | | \ / | | \
184 / z r-----s \ / P z r-----s P \
185 H | \ C H o | \ o C
186 | | One \ | | l | \ l |
187 | y-x Hole t | ========> | y y-x t y |
188 | / | | | g / | g |
189 G \ | D G o \ | o D
190 \ / v---u / \ n / v---u n /
191 \ \ / / \ 1 \ / 2 /
192 \ \ / / \ \ / /
193 F-----w--------E F-----w w--------E
195 Incorrect Correct
197 Figure 4: Specification of Hole with Multiple Outer-Boundary
198 Intersections
200 Similarly, a polygon that is enclosed entirely within a hole from
201 another polygon (i.e., an "island") is a separate polygon.
203 o--------------o
204 / \
205 / +--------------+ \
206 / |%%%%%%%%%%%%%%| \
207 o |%%o--------o%%| o
208 | |%/ Island \%| |
209 | |%\ /%| |
210 | |%%o--------o%%| |
211 o |%%%%%%%%%%%%%%| o
212 \ +--------------+ /
213 \ /
214 \ /
215 o--------------o
217 Figure 5: Holes With Enclosed Polygon (Island)
219 Rule 3: A hole MUST be formed from a legal linear ring in
220 accordance with [geoshape], except that points are
221 specified in a clockwise direction.
223 Holes are specified in clockwise direction so that the upward normal
224 is opposed to the upward normal of the exterior boundary of the
225 polygon. Note that [geoshape] stipulates that exterior boundaries
226 are specified in anti-clockwise order.
228 There is no restriction on the number of points that are used to
229 express the perimeter of either exterior or interior boundaries.
231 4. GML Polygons
233 The GML encoding of a polygon defines a enclosed exterior boundary,
234 with the first and last points of boundary being the same. Consider
235 the example in Figure 6.
237 F--------------E
238 / \
239 / \
240 / \
241 A D
242 \ /
243 \ /
244 \ /
245 B--------------C
247
248
249
250 43.311 -73.422
251 43.111 -73.322
252 43.111 -73.222
253 43.311 -73.122
254 43.411 -73.222
255 43.411 -73.322
256 43.311 -73.422
257
258
259
261 Figure 6: Hexagon and Associated GML
263 Note that polygon vertices in Figure 6 are expressed using
264 elements for clarity. The vertices can also be expressed using a
265 element.
267 5. Holes in GML Polygons
269 A hole is specified in the polygon by defining an interior boundary.
270 The points defining the internal boundary define the area represented
271 by the hole in the primary (exterior) polygon. The shaded area in
272 Figure 7 is represented by the 4 points of the interior boundary
273 specified by (w,z,y,x).
275 F-------------E
276 / \
277 / w-------------x \
278 / |/////////////| \
279 A |/////////////| D
280 \ |/////////////| /
281 \ z-------------y /
282 \ /
283 B-------------C
285
286
287
288 43.311 -73.422
289 43.111 -73.322
290 43.111 -73.222
291 43.311 -73.122
292 43.511 -73.222
293 43.511 -73.322
294 43.311 -73.422
295
296
297
298
299 43.411 -73.322
300 43.411 -73.222
301 43.211 -73.222
302 43.211 -73.322
303 43.411 -73.322
304
305
306
308 Figure 7: Hexagon with Hole
310 6. Service Boundary Specification and Selection Algorithm
312 A service boundary is represented by a polygon that may have many
313 vertices. The enclosed area of the polygon represents the area in
314 which a service, expressed as a service URN, maps to a single URI.
316 Figure 7 is used to illustrate two service boundaries. The first
317 service boundary A->F shall be referred to as area-A, and the second
318 service boundary w->z shall be referred to as area-w. Furthermore,
319 area-A is directly represented by the GML encoding provided in
320 Figure 7. Area-w is represented as a hole in area-A by the interior
321 boundary. Since area-w is also a service boundary, a separate
322 polygon describing this area is also required and is shown in
323 Figure 8 (note the reversal of the vertices).
325
326
327
328 43.411 -73.322
329 43.211 -73.322
330 43.211 -73.222
331 43.411 -73.222
332 43.411 -73.322
333
334
335
337 Figure 8: GML for Area-w
339 Service mappings for these boundaries might be provided by a LoST
340 server in the form shown in Figure 9.
342
347 Outer Area Police
348 urn:service:sos.police
349
350
352
353
354 43.311 -73.422
355 43.111 -73.322
356 43.111 -73.222
357 43.311 -73.122
358 43.511 -73.222
359 43.511 -73.322
360 43.311 -73.422
361
362
363
364
365
366 43.411 -73.322
367 43.211 -73.322
368 43.211 -73.222
369 43.411 -73.222
370 43.411 -73.322
371
372
373
374
375 sip:area-A-pd@example.com
376 xmpp:area-A-pd@example.com
377 000
378
380
385 Inner Area Police
386 urn:service:sos.police
387
388
390
391
392 43.411 -73.322
393 43.211 -73.322
394 43.211 -73.222
395 43.411 -73.222
396 43.411 -73.322
397
398
399
400
401 sip:area-w-pd@example.com
402 xmpp:area-w-pd@example.com
403 000
404
405 Figure 9: Service Boundary Specifications
407 It is considered likely that LoST servers will need to provide
408 responses sufficiently quickly to allow real-time queries to be
409 performed as part of an emergency call routing flow. It is for this
410 reason that databases supporting native geospatial query techniques
411 are desirable and that service boundary specifications that are
412 easily mapped to internal data structures are preferred. Using
413 interior boundaries makes support for this operation easy, while
414 allowing an arbitrary number of holes in a service boundary to be
415 specified.
417 Each polygon is stored in the geospatial database and mapped to a
418 service URN and destination URI. Many geospatial databases natively
419 support polygons with interior exclusions. Without native support,
420 interior boundaries can be stored against the polygon and can checked
421 separately. A location falls within the area described by a polygon
422 if it is within the exterior boundary and not within any interior
423 boundary.
425 In the above example, if a location falls within the interior
426 boundary, it maps to the "Inner Area Police" service; likewise, if a
427 location falls within the exterior boundary, but not within the
428 interior boundary, it maps to the "Outer Area Police" service.
430 7. Security Considerations
432 Constraining the form of a polygon representation as described in
433 this document does not introduce new security considerations.
435 8. IANA Considerations
437 This document has no IANA actions.
439 [RFC Editor: please remove this section prior to publication.]
441 9. Acknowledgements
443 Thanks to Carl Reed for input provided to the list some months back
444 and for reviewing this document. Thanks to Michael Haberler for
445 suggesting that such a specification is required. Thanks to Avery
446 Penniston for review and feedback.
448 10. References
450 10.1. Normative References
452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
453 Requirement Levels", BCP 14, RFC 2119, March 1997.
455 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
456 Tschofenig, "LoST: A Location-to-Service Translation
457 Protocol", RFC 5222, August 2008.
459 [geoshape]
460 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
461 Application Schema for use by the Internet Engineering
462 Task Force (IETF)", Candidate OpenGIS Implementation
463 Specification 06-142r1, Version: 1.0, April 2007.
465 10.2. Informative References
467 [I-D.ietf-ecrit-lost-sync]
468 Schulzrinne, H. and H. Tschofenig, "Synchronizing
469 Location-to-Service Translation (LoST) Protocol based
470 Service Boundaries and Mapping Elements",
471 draft-ietf-ecrit-lost-sync-09 (work in progress),
472 March 2010.
474 [ISO-19107]
475 ISO, "Geographic information - Spatial Schema", ISO
476 Standard 19107, First Edition, 5 2003.
478 Authors' Addresses
480 James Winterbottom
481 Andrew Corporation
482 Andrew Building (39)
483 Wollongong University Campus
484 Northfields Avenue
485 Wollongong, NSW 2522
486 AU
488 Email: james.winterbottom@andrew.com
490 Martin Thomson
491 Andrew Corporation
492 Andrew Building (39)
493 Wollongong University Campus
494 Northfields Avenue
495 Wollongong, NSW 2522
496 AU
498 Email: martin.thomson@andrew.com