Geometry Boost List: [ggl] Polygon concept change and Boost.Polygon

Subject: [ggl] Polygon concept change and Boost.Polygon
From: Barend Gehrels (barend.gehrels)
Date: 2010-12-14 12:11:31

Hi,

I propose to move this discussion to the Boost-dev mailing list as it is 
not specific to Boost.Geometry.

Regards, Barend

On 14-12-2010 17:12, Simonson, Lucanus J wrote:
> I forgot to mention that the scaling function should accept a policy 
> for whether to throw when snapping out of bounds floating point value 
> to integer, with default being to throw.
>
> ------------------------------------------------------------------------
> *From:* ggl-bounces_at_[hidden] 
> [mailto:ggl-bounces_at_[hidden]] *On Behalf Of *Simonson, Lucanus J
> *Sent:* Tuesday, December 14, 2010 7:50 AM
> *To:* Generic Geometry Library Discussion
> *Subject:* RE: [ggl] Polygon concept change and Boost.Polygon
>
> Yes.  I view the polygon types I provide as incidental, I need them to 
> implement the library, but the intention is for user defined polygon 
> types to be used by users who have real applications and legacy type 
> systems.  For casual users the polygon types I provide are 
> convenient.  Eventually a user of both libraries should be able to 
> adapt their type for a concept in one and then call a macro that 
> adapts it to the concept in the other using the interface of the 
> first.  Then the user calls ggl::area(my_polygon) and 
> gtl::area(my_polygon) freely.  While we have some overlap there are a 
> number of algorithms that exist in only one library or the other.  The 
> issue of floating point versus integer coordinate types remains 
> problematic, of course, and will impede mixing and matching algorithms 
> with each library.  Perhaps we can write a integer-to-double and 
> double-to-integer polygon interface adaptor that snaps to integer in 
> one direction and casts to floating point in the other and make it an 
> optional part of the glue between the concepts of the two libraries.  
> That wouldn't be without its problems, but it would prevent the user 
> from having to do it manually.  A scaling factor could be looked up by 
> a function call that would return 1.0 by default and provide a point 
> of customization for the user to specify their own scaling.  VLSI is 
> measured in microns and we work in thousandths of microns.  If the 
> user wanted to use micron as their unit with ggl and scaled integer at 
> the thousandth or ten thousandth of a micron with gtl that could be 
> made automatic and transparent.  The user might then prefer to call 
> ggl::area() only because they prefer to see the area result in square 
> microns while they might call gtl::perimeter because they like to see 
> length in integer units of one thousandth of a micron.
> ------------------------------------------------------------------------
> *From:* ggl-bounces_at_[hidden] 
> [mailto:ggl-bounces_at_[hidden]] *On Behalf Of *Bruno Lalande
> *Sent:* Tuesday, December 14, 2010 1:33 AM
> *To:* Generic Geometry Library Discussion
> *Subject:* Re: [ggl] Polygon concept change and Boost.Polygon
>
> So basically, your mean adapting the Boost.Polygon concept rather than 
> one of its models, so that any model can work? I agree it would be 
> even greater indeed. And the changes Barend just did about making the 
> library return-semantic-agnostic should help a lot.
>
> Bruno
>
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl

-- 
-------------------------------------
Barend Gehrels
-------------------------------------
http://www.erplex.com
http://trac.osgeo.org/ggl
http://www.geodan.nl
-------------------------------------
Geodan
President Kennedylaan 1
1079 MB Amsterdam
The Netherlands
-------------------------------------
Tel: [phone]
Mob: [phone]
Fax: [phone]
-------------------------------------
E-mail: barend.gehrels_at_[hidden]
Kvk-nummer: 33 207089
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101214/423ac6d6/attachment.html