Hi all, here is my review. I followed all the discussions since your first preview, because I am interested in a good geometry library. I liked your initial design and was really impressed by the cooperative improvement during the iterations. But before going into details, I think that GGL should become a part of boost, so make this a Yes vote.
- What is your evaluation of the design?
I think it is clean and easy to follow. The one exception to this is the way union / intersections are handled, which I have not fully understood yet. I would have expected to be able something along the lines of: polygon p1 = ...; polygon p2 = ...; polygon_set ps1 = make_union(p1, p2); polygon_set ps2; intersection(ps1, p2, ps2); I also don't find it too obvious how the extention to 3d geometries is going to work, yet.
- What is your evaluation of the implementation?
I have only skimmed through it, but it looks quite clean. It is easy to find each entity, and see what they are doing.
- What is your evaluation of the documentation?
On the whole I am very pleased with the documentation, its easy to read and reasonably complete. I have a general problem with doxygen generated docu with regard to generic libraries. It not easy to separate the important classes and fuctions from the implementation details. GGL helps with this through Grouping by modules and a overview Page, but it could be even better. I think the Modules should them self be further grouped, and the most important should be highlighted. Something along the lines of (just examples, no informed reordering): Modules Page ------------ Entities (?) Geometries Coordinate Systems (?) Algorithms (? Functions) distance union ... Utility / Machinery core concepts traits ... And ideally (but I think that it is not feasible in doxygen) better Navigation inside these Groups
- What is your evaluation of the potential usefulness of the library?
I think it is immensely useful to have this in boost. An example like qt_example shows that geometry plays a role even in everyday programming and is not specific to any particular (niche) domain. I think it is important that we have a common vocabulary which scales form there to very complex and involved algorithm. I would love to have it extended to 3d Geometry (especially Polygon/Triangle meshes) but I wouldn't make my vote depend on this. However I think that 3d should become part of the default distribution once it is there.
- Did you try to use the library? With what compiler? Did you have any problems?
Compiling some example and playing around with them a bit. No problems on OS X 10.6 with gcc 4.2.1
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
As stated above reading the Docu, and all communication on this list from the get-go. Glancing at the Implementation, and trying out some examples.
- Are you knowledgeable about the problem domain?
Yes, I work in medical visualisation, and have developed geographical tools while studying. I have used CGAL and (unfortunately) ACIS and evaluated a few others, so I have a good Idea what a c++ geometry library should or should not look like. Kind regards, and great Work Fabio Fracassi