Subject: Re: [Ecrit] Direction of holes draft

From: "Marc Berryman" <[email-masked]>
Date: Mon, 22 Jun 2009 20:09:11 -0500

Unfortunately in the real world there are holes and interior polygon in many places and this feature needs to remain in the document as provisioning as discussed in a nightmare for GIS users and (it is true) not the way most think of the issue.

Thanks,
Marc B.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: ECRIT <[email-masked]>
Sent: Mon Jun 22 20:01:49 2009
Subject: [Ecrit] Direction of holes draft

Cullen raised some concerns about the additional feature that this document requires.  He suggested that an alternative would not require support of interior polygons, or holes.

I'd like to confirm that the WG is OK with taking the document as is, without making this proposed change.

Thanks,
Martin

Below is a summary of our discussion:
--
The alternative does not use the <interior> element of the polygon to create holes.  Instead, polygons are sliced into two or more sections so that the “holes” became external to each section.  Each section is created as a separate mapping.

We concluded that the alternative solution proposed is viable, but the existing method is best when considering the deployment implications.

Alternative pros:

No additional functions required by the protocol.
No additional functions required by LoST implementations.

Alternative cons:

This isn’t how people think about the problem.
Regions with holes would need to be divided up by a provisioning system into multiple regions with separate mappings.
This likely requires changes to the provisioning and GIS systems that feed LoST, these systems already exist and therefore the cost is higher (at least we know that LoST implementations barely exist).
The existing solution is already documented and agreed.

--

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Jun 2009 20:31:04 -0500

Thanks Marc,

This was a major point in favour of keeping the draft as it is: we want to try to minimize the impact on existing GIS systems.  They use holes; therefore, we need to use holes too.

--Martin

> -----Original Message-----
> From: Marc Berryman [mailto:[email-masked]]
> Sent: Tuesday, 23 June 2009 11:09 AM
> To: Thomson, Martin; [email-masked]
> Subject: Re: [Ecrit] Direction of holes draft
> 
> Unfortunately in the real world there are holes and interior polygon in
> many places and this feature needs to remain in the document as
> provisioning as discussed in a nightmare for GIS users and (it is true)
> not the way most think of the issue.
> 
> Thanks,
> Marc B.
> 
> Cullen raised some concerns about the additional feature that this
> document requires.  He suggested that an alternative would not require
> support of interior polygons, or holes.
> 
> The alternative does not use the <interior> element of the polygon to
> create holes.  Instead, polygons are sliced into two or more sections
> so that the “holes” became external to each section.  Each section is
> created as a separate mapping.
> 
> We concluded that the alternative solution proposed is viable, but the
> existing method is best when considering the deployment implications.
> 
> Alternative pros:
> 
> Regions with holes would need to be divided up by a provisioning system
> into multiple regions with separate mappings.
> This likely requires changes to the provisioning and GIS systems that
> feed LoST, these systems already exist and therefore the cost is higher
> (at least we know that LoST implementations barely exist).