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
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
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
===== 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
===== Did you try to use the library? With what compiler? Did you
===== 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk