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