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