Hi,
GIS is my work area, so I know it's huge, but it seems like you are trying to tackle GIS + generic geometry library. I don't get the impression that game programmers, for example, will enjoy or use this library. Polygons are not closed (and rarely used, only triangles are) in games, and cannot have holes, and any error checking to determine otherwise is wasteful. Winding is handled by the rendering API, and is also rarely, if ever, checked since the model exporter will have enforced the correct winding.
Me and Barend discussed a bit about this, as I'm personally more concerned about game programing than GIS. So I guess that until now, my participation to the library has been influenced by this point of view. What you say is true about what the library currently *provides* (GIS-oriented algorithms, even if polygons with holes can be used in games contrary to what you say, to display 2D vectorial fonts for instance). But it's false about the *potential* of the library, and this has always been my main concern since the beginning. I focused my efforts until now on the kernel because I think that the different application domains (GIS, games or whatever) won't necessarily share the same algorithms but can share the same kernel. If an algorithm is to slow because it can handles polygons with holes while game programmers use plain triangles, the key of the problem is to know if the library has been designed generically enough to sort that out. If mechanisms like tag dispatching and/or concept refinement are present and designed so well that I can add a triangle concept, take advantage of the algorithms already present for polygons, and specialize the ones that deserve to be, there's no problem. We can do that and game programmers will be happy with the library, like GIS ones were happy with the stuff already present. So the kernel is the key. Right now Barend wants to write more algorithms, and those algorithms are GIS-oriented since this is his domain. This doesn't remove anything from the library. It can even improve the kernel: as Douglas Gregor writes in http://tinyurl.com/cw3qk5, "concepts are neither designed nor invented, they are discovered through the process of lifting many algorithms within the same domain." So writing more and more algorithms, even targeted toward one application domain, can only give a chance to improve the kernel. Of course it would be good to make the same in other domains as well, and as soon as I have more time, I'll try to test the kernel against some more game-oriented algorithms. Now the question is: is a Boost.Geometry library meant to contain all the stuff necessary for every application domain (which is basically impossible)? Personally, my approach would rather be to have Boost.Geometry proposing just a kernel and the most basic algorithms like point arithmetics, dot and cross products, etc... and having extensions for more precise application containing potentially a lot of algorithms... Regards Bruno