Hi Phil, Thanks for your interest in our library, now and in the past.
The documentation seems very much focused on "how it works", which is of course useful for reviewing the design, but more "what it does" and "how to use it" content would help me to actually try it with some examples.
For example, I have a Point<T> class and I would like to "teach" the library about it. From the "Design rationale" page I can see that a number of traits have to be defined, but I don't see a concise reference to what I need to do. Looking at the example "c01_custom_point_example.cpp" I see that there are some macros e.g. GEOMETRY_REGISTER_POINT_2D (not a Boost-style macro name by the way) but I don't see any documentation for what these do. I guess that it defines some traits specialisations, right? Right. The custom examples now all make use of the macro's but I think for teaching purposes we could have left one traits class. However,
There were more remarks about the documentation, its structure and its content, and we hope to enhance this in the near future. If our library is accepted we might migrate to Boost Books because it seems that most libraries do have that format. there is one left in the tests, file libs\ggl\test\test_common\test_point.hpp , so that might give you more background.
Does anyone know how to get Doxygen to create next/prev buttons for navigating between the pages in the e.g. "related pages" section?
Is it possible to note which versions of the Boost library dependencies are needed?
That is somewhere there on the page "Relation to Boost and std libraries". Or probably you don't mean that, it all runs fine using Boost 1.40.0. Does this answer your question?
I'm not convinced that overloading e.g. distance() so that it works with all combinations of geometries is a good idea. If I wanted to know the distance from a point to a polygon I'd be happy to write distance_pt_to_poly(a,b).
The whole library is designed like this and I think it is good and generic. You're now able to use all functions in template environments, where you don't know if you're handling a point or a line. If you write distance_pt_to_poly, you have to know the context...
Having the overload makes it possible for me to accidentally pass the wrong things and get no error. And there is the question of what is meant by distance "to" a polygon - is it to the nearest point, or the centroid, etc? Sure, that is a good question. We'll mean the OGC distance because it is an OGC function. To be more clear, this is the distance to the border. There were earlier questions about this, because sometimes you even want to know the distance from a point inside a polygon to the border. I believe it was you who asked that once. This is currently an open point (it is not defined by OGC, but we can deviate sometimes - even give a negative value back would be possible).
I believe that heterogeneous co-ordinate types (e.g. latitude and longitude of one type and altitude of another) are not supported, right?
No, if you write that in this way, it is not supported. You can define a point (lat, long) with altitude as an attribute. Then it is your choice, so it is possible then. But if you make a 3D point using lat long coordinates, and it makes sense of course, then the altitude should be the same coordinate type as lat and long... Regards, Barend