A few more notes after looking through the documentation at length: - I agree that it makes sense to make Point a concept. But it looks like other geometries need it even more. For example, geometry::polygon<> encapsulates a fairly complicated data structure but adds little functionality on top of it; linestring and linear_ring provide even less. On the other hand, I imagine the algorithms don't need full container functionality from the geometries in most cases and could get by with a sequence (pair of iterators). Perhaps formulating concepts around those entities would help generalize the algorithms even further. I realize that at this point I should be suggesting an alternative design :) but to do that I'll have to look at the algorithm implementations first, not just the interfaces... and I'll try to get to it later. My own generic algorithms usually dealt with sequences alone, STL-style but I've never parameterized them as extensively as you do it. - Arithmetics with points and vectors (operator overloading and simple functions): it is mostly syntactic sugar, but it tends to make code shorter and more readable. I'm sure you have some, maybe a lot of it, but the docs are a bit hard to navigate in that respect. - Another 2 types of geometries I found useful in certain algorithms (e.g. computing straight skeletons or line widening) are infinite lines and rays, along with segments that you already have. The key operations for them are of course intersections. - Point to linestring distance algorithm should be able to provide the information (iterator?) as to which segment (or vertex) of the line turned out to be the closest. - Something I was thinking about but has never done yet... which of the geometrical algorithms could be effectively implemented on sequences of polynomial curve segments (quadratic and cubic Beziers are my natural favorites)? If feasible, this would be a very powerful tool for 2D graphics. More to come. ...Max...