Re: [Ecrit] Direction of holes draft

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:MBerryman@911.org]
> Sent: Tuesday, 23 June 2009 11:09 AM
> To: Thomson, Martin; ecrit@ietf.org
> 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.
> 
> ----- Original Message -----
> From: ecrit-bounces@ietf.org <ecrit-bounces@ietf.org>
> To: ECRIT <ecrit@ietf.org>
> 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
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------------------------
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]