Subject: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (Specifying Holes in LoST Service Boundaries) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 24 Feb 2010 11:16:00 -0800 (PST)

The IESG has received a request from the Emergency Context Resolution 
with Internet Technologies WG (ecrit) to consider the following document:

- 'Specifying Holes in LoST Service Boundaries '
   <draft-ietf-ecrit-specifying-holes-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-03-10. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17331&rfc_flag=0

---

From: "Avery Penniston" <[email-masked]>
Date: Thu, 25 Feb 2010 11:19:25 -0600

Hello,

I had a couple of comments on draft-ietf-ecrit-specifying-holes:

1.) In figure 6 and 8 the <gml:interior> ring has its points specified
in a counterclockwise order, but I think the interior ring's points
should be ordered clockwise.  I believe it is common practice (and
perhaps even mandated) that the interior ring's point orientation should
be opposite orientation of the polygon's exterior ring point
orientation.  Since GML 3.1.1. and the [geoshape] document referenced in
the draft both define a surface's upward normal as counterclockwise this
would make the interior ring's orientation clockwise. 

2.) The last paragraph on page 12 talks about storing holes as polygons
in a separate table.  I think this statement may be going a bit far in
specifying technology specific details.  In general, spatially enabled
databases support the notion of interior rings and can quickly calculate
polygon intersections, even between polygons that contain holes, without
the need for a secondary check against an exception table for hole
polygons.  

Avery
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of The IESG
> Sent: Wednesday, February 24, 2010 1:16 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes
> (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
> 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =17331&rfc_flag=0
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 26 Feb 2010 02:30:26 +0800

Hi Avery,

Thanks for your comments.
If we have a counterclockwise ring then you are right, this is wrong. I will take a look.

It has been so long since this draft left the WG that I will need to go and look at separate table comment. I do recall that when we wrote the draft we were asked to provide some guidance as to how the presence or holes might be checked for.

Cheers
James

________________________________________
From: Avery Penniston [[email-masked]]
Sent: Thursday, February 25, 2010 11:19 AM
To: Winterbottom, James; Thomson, Martin
Cc: [email-masked]
Subject: RE: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard

Hello,

Avery
[email-masked]