Barend worked a lot on algorithms so he brought his part, that is GIS. This doesn't prevent from bringing other application domains.
Very good, it is somewhat what I had understood.
the user part, I sincerely think that what we have is sufficient .
Well, maybe it is sufficient, but my point is only if someone checks the doxygen "classes" for example, he can be quite confused by all the templated elements. Maybe I am only not enough used to read (so much) template-driven library documentation. The question is the needed level to read the doxygen document. Maybe some elements should not appear in the doxygen to make it clearer for the user ?
So typically, some of the things you are asking for could be included in the kernel (lines, rays...) and other ones would rather come as specific extensions (frustums, meshes...).
Hope this makes sense to you?
Yes completely. But I have a question about extension. What is the complexity of extending for a new kernel 'type' for example ? Because STL is known for its "number containers + number algorithms" system. Is it comparable ? Or is it more a "Sum for each element of ggl kernel of: "number of algorithms supported by the ggl::element"" ?
But just to show a small sample of a geometry created with GGL using transformations and 3D, in the GIS context, you can look at http://trac.osgeo.org/ggl/wiki/WhoUsesGGL
Thanks!
Within GGL you can present points in different coordinate systems. Even if they are both cartesian, then can be marked as different
Ok very good, I missed it. Best regards, Pierre Morcello