On Thu, Nov 26, 2009 at 5:21 AM, Barend Gehrels <barend@geodan.nl> wrote:
The reason for the assign with 4 functions is to assign the sphere completely, in one call.
Right.
I do not understand exactly what you dislike, but probably it was something that seems to be not used or moved?
Simply that the 2- and 3-type overloads completely assign 2- and 3-d geometries respectively. I would prefer the 4-type version to completely assign a 4-d geometry. Perhaps the interface already supports this (not the implementation), since the function is overloaded on the geometry type.
The example code on the main page didn't compile, which isn't a problem in and of itself.
This is surprising, as all examples are extracted from real, compiling code... Be it, indeed, that headerfiles are not extracted (more reviewers have mentioned this and this will be addressed)
There was nothing wrong w/ the code itself. The issue was that it required headers, other than ggl.hpp, to compile. It took a bit of leg-work to figure out what I needed to include.
We understand the flaws and drawbacks of the documentation, but for your information, the "modules" page lists all of the algorithms available....
I went back later, and was able to find the algorithm in question from this page. Thanks!
However, it is a shame that the library lacks a first-class spatial index capability in it's present state (e.g. what is up for review). ...
It is available as an extension, the reasons for non-inclusion were: - we want to improve performance - we want to enhance the interface
So will it be moved *into* the library-proper at some point, or will it always remain an extension? Thanks, Jon