Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-11-16 15:19:31

Jose wrote:
> Hi,
> 
> I am not expert in geometry but what matters is that boost continues
> to provide generic libraries (if possible !) like BGL, GIL, ..
> 
> I think there is no blame on library authors which make a huge effort.
> What was broken is the review process, and some of the reasons why the
> review process was broken were:
> 
> 1) The result of the review was 6 positive to 4 negative, when boost
> normally aims for consensus. This is the most objective point. Also,
> the issues the review manager was proposing to be fixed would not
> change the votes as the library was not appropiate even for 2D geo
> applications

There were two primary issues the no votes pointed out.  One was performance, which it turns out was a red herring exactly as the review manager concluded.  The other was support for floating point.  The interfaces support floating point while the polygon clipping algorithm does not.  It is unreasonable to ask me to implement a 2nd algorithm equal in scale to the first, since that is what would be required to add floating point support.  Once I am able to call a good implementation of polygon intersection that is licensed under the boost license the 2nd objection will also be addressed.  I am hoping that GGL might one day contain that implementation, but right now it does not.

> 2) The scope of GTL was changed before the review (see snippet 2 at
> the end) but the review docs still mention a wider app focus (see
> snippet 1 at the end). This confusion appeared when GTL was being
> reviewed.

There is no inconsistency there.  Polygons are used in GIS and fixed point booleans are used in GIS.
 
> 3) The review manager didn't have time for the review (if you look at
> the apology at the beginning of the review email summary)

The apology was for the delay releasing the result of the review.  During the review the review manager was engaged and had already decided the result of the review shortly after the review concluded.  The review manager was very responsive to my emails during and shortly after the review.  
 
> 4) The GGL library proposal, which had been iterating the design with
> input from boost, in my opinion received an unfair treatment
> in the way the schedule was managed.

My library has actually been iterating the design with input from boost for longer than GGL.  I did it in a more low key way than Barend, but I did iterate three or four times with the boost community on design and implementation issues over a period of years.  What I think is unfair to GGL is that it was brought to review too soon.  There are a number of issues and features not yet implemented that I think would have been better addressed before a formal review rather than after.  Personally I think this should have been another preview rather than a review of GGL, that way we could provide feedback to Barend without people jumping to his defense and saying things are unfair.

Regards,
Luke