[boost] GGL Review

Subject: [boost] GGL Review
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2009-11-22 17:08:21

I believe GGL should be accepted as Boost.Geometry

My main concern is the number of things which are incomplete.   
Certainly the obvious lackings such as missing boolean operations,  
clockwise versus counterclockwise polys, closed versus open polys,  
should be fixed or rationalized before this is released.  It sounds  
like Barend and friends have promised to complete all of these things.

I hope Hartmut is willing to manage a mini-review when the authors  
believe this is ready for release, to make sure that all concerns  
raised in the first review have been addressed in some way.  I asked  
the same for Boost.Polygon; I think it is even more important here  
because the scope is much broader, whereas Polygon seems to have  
covered integer polygons pretty well.

Then there are a lot of things which the authors claim are possible  
but which will probably need to be contributed by others: triangles,  
3D, ellipses, splines, homogeneous coordinates ...  I am confident  
that the authors will help these things to happen, and I have no  
reason to think that they won't fit in.

OTOH it may be that some concepts do not fit in; for example, it's not  
clear to me whether or not the 45/90 degree concepts of Boost.Polygon  
are orthogonal or skew.  It is going to take some time for everyone to  
figure this out, and I think that Boost is the right forum for this  
discussion.  I hope that future domain libraries are developed as  
extensions to GGL, but it may be that they demand their own  
frameworks.  I think it's naive to assume outright that all can fit  
into one framework, but I am optimistic.

Both libraries allow external data structures and concepts to be  
adapted to them, and so the first step in determining their  
commonality will be to write those adapters.  I'm pleased to see that  
Luke has already started this effort from his side.  Oh, for concept  
maps!

My two cents on floating point robustness: in many applications, the  
use of geometrical computations is "one-way": there is a model, some  
operations are applied to produce coordinates, which are then output.   
This is mostly true in the domain I wish to use this library, graph  
drawing (network visualization).  If the results are not fed back into  
the system, floating point robustness is not going to be an issue.   
While some work could probably be done here, I think it is OK that  
users must understand the issues with floating point for best results.

I'd like to see GGL run with Boost.Polygon's robustness tests and  
randomly generated efficiency tests.  It sounds like this has already  
begun.

A couple of people asked for GIL examples.  This would require a line  
and curve bitmap rendering library, which would be a really cool  
addition to Boost.

===== How much effort did you put into your evaluation? A glance? A  
quick reading? In-depth study? =====

Sorry I have not had time to conduct a more thorough review.  I have  
spent a couple of hours looking at the documentation and examples, and  
have read the review discussion thoroughly (another five or six  
hours).  I've also followed most of the discussion in the past.

===== What is your evaluation of the design? =====

It seems very well thought out, for the domain which has been explored  
so far.  The only concern I have (which I haven't thought out  
thoroughly) is the absence of hierarchical concepts.  IIUC a new class  
must subscribe to all concepts, not just the most derived.  This seems  
like it might get onerous when there are a lot more concepts / if the  
granularity is reduced.

===== What is your evaluation of the implementation? =====

 From the discussion and from the presentation at BoostCon, I  
understand that not everything which is described is implemented, and  
everything which is implemented does not completely live up to the  
standards which the library sets.

Again, I think these discrepancies should be resolved either by  
implementation or by narrowing the scope and documenting.  As is, it's  
rather confusing.

===== What is your evaluation of the documentation? =====

I'd like to see an overview of the concepts - there are the detailed  
descriptions in doxygen but nothing written in English.  :-)  Doc  
seems mostly to consist of very technical rationales, which are good,  
and then examples, which are also good.  But not much overview.

I think doxygen is convenient for developers but not very useful for  
users, because of the high structure/content ratio.

===== What is your evaluation of the potential usefulness of the  
library? =====

Very useful.

===== Did you try to use the library?  With what compiler?  Did you  
have any
      
problems 
?                                                               =====

Not yet.

===== Are you knowledgeable about the problem domain? =====

As others have pointed out, it's not clear the domain is well- 
defined.  I'm not familiar with GIS.  I have developed visualization  
and graphics applications which need 2D geometry for more than a  
decade, and this looks like it will serve many of my needs.

I wish both this review and the Polygon review had been delayed until  
the libraries were more mature.  As it is, we're going on trust that  
the promise will be fulfilled.  But I understand that there are social  
and real-world constraints as well as technical and I think it's best  
that both libraries are accepted a little early so that the community  
has a chance to cooperate in lifting the concepts.  I am very happy to  
see the authors resolving some of their differences.  There's a long  
road ahead...

Cheers,
Gordon