This is a topic I find extremely interesting since by the will of fate I keep coming back to it in the course of my everyday work. In fact, I have implemented (fully or in part) a similar set of library facilities 3 times in a row... and I can't very well opensource any of the three implementations :( Nothing prevents me from collaborating on an existing open source project though :) I have only glanced briefly through the documentation so my comments may be based on an incomplete picture; I apologize in advance if that's the case. Nevertheless I am going to respond right away just so you know you're not alone ;). I'll also try to spend more time reviewing your library later today. - I very much like the traits-based approach to determining the type of calculation results. However a good extensible facility for deriving the result type from argument types appears to be generally useful and not at all specific to geometry. Unless there is one already in Boost (I am not aware of it and quick check of the docs didn't help), perhaps it may be introduced as a separate library? - While generalized point types (2D vs. 3D and XY vs. lat/lon) are OK, it is often extremely useful in graphics code to make your objects fit the underlying representation of an externally defined structure (such as POINT type in Win32) -- for example by publicly or privately inheriting from it. This lets you use e.g. vectors of points as arguments for system APIs. Can be done by adding an extra template argument (with a default) to point<> and moving most of the implementation details into a traits class. - There is a box type but not a (1D) range type (I don't think you allow 1D points, or do you?). It is often convenient to define operations on bounding rectangles in terms of ranges. The comment about making point types compatible with externally defined structure applies to boxes too. - I didn't find any facilites for linear transformations in your list. Am I not looking in the right place or they aren't there? If the latter, it is probably the biggest omission. Or do you think this need is best served with uBLAS? I have no idea if this can be done using uBLAS in both efficient and convenient way so would like to hear everyone's thoughts. I am very much used to writing things like: pt = shift( dst_offs ) * rotate( angle ) * shift( -src_offs ) * pt; or when it is a repeated operation: transform2D xf = shift(dst_offs) * rotate(angle) * shift(-src_offs); ....... pt = xf * pt; or maybe even for_each( pts.begin(), pts.end(), _1 = xf * _1 ); // using lambda - In 2D geometry, very many computations can be most efficiently expressed in terms of dot product and cross product, so it wouldn't hurt to have these operations implemented as part of the library. It probably makes sense (I haven't done that before) to have a type for offset vectors in geometrical sense separate from points: vec = pt - pt; pt = pt + vec; et. al. The difference is that the offset part of a linear transformation should apply to point but not to vector. Again, is this something best done with uBLAS? Ok, really need to go back to work. I'll probably have more to say on this later. ...Max...