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

Subject: [ggl] Polygon concept change and Boost.Polygon
From: Simonson, Lucanus J (lucanus.j.simonson)
Date: 2010-12-14 11:13:04

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 glu
e 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101214/168ec29d/attachment.html