From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-26 06:38:19
> I am extremely interested in a boost affine geometry library, but given
> the history on this mailing list I suspect the best approach might be to
> start with less rather than more. I don't know if this works with boost
> libraries but I think I would like it if a minimal
> point/vector/coordinates library, which basically just provided concepts
> and models for proof of concept, was accepted and additional algorithms
> on top of them came later.
> -- John C. Femiani
Thanks for all answers and comments on my preview. I knew that the
subject is difficult and lends itself to many discussions. I will not
answer all mails individually so I paste some snippets to cover most things.
First about the vector/matrix calculations. They are intentionally left
out the library, because it is a separate thing. You can do geometry
without (much) vector/matrix calculations and you can use vector/matrix
without doing geometry. Besides that it is already in Boost: uBLAS
contains vector/matrix calculations. So I decided to not do it again. To
make this more clear I reworked a sample and added it to the preview:
http://geometrylibrary.geodan.nl/examples.html, see 6 transformation
example. Besides transformations, there are small vector calculations
necessary inside any geometry library. They are now coded inside but
another library could be used. This is also explained on the example-page.
Then about the point class:
> This has been well discussed many times: make Point a concept and
> allow many models of the Point concept. It is a mistake to have
> a single do-it-all point class. What if I want a 2 dimensional
> point with a short for x and a long for y? Your class can never
> satisfy all possibilities. The best strategy is to allow for
> multiple point models be usable in your algorithms
> cout << distance(p1, p2) << endl;
> cout << distance(p2, p3) << endl;
> Joel de Guzman
This is how it is implemented. More points are possible, two points are
provided, strategies can be defined for any point type. The distance
calculation can be done exactly as stated above.
About the "point concept". I've looked at the concepts, downloaded and
tried the concept compiler. However, in this geometry library there are
more concepts possible. As long as you attach the right strategies with
the points, you can use any point, at least, that is the intention. I
provided a basic point with an array and neutral names as "value", but
even that is not really necessary. In the documentation I added notes
about the concepts and requirements, with some classes, but not yet with
all of them.
About the point_xyz: I intentionally left that out to not give the
intention that the library is a 3D library. 3D could be added but at
this moment it is not. Algorithms are for 2D points, and after the first
preview I added the latlong points as well (but I didn't implement all
strategies for them).
Finally about the compiletime area calculation: sorry that I've
mentioned that, it was really a small experiment. Because there is
interest I will relook at it, but it should not distract the list from
the focus: the preview, without vector/matrix calculations, with affine
geometry and latlong geometry, and if that might be a starting point for
a boost geometry library candidate.
Best regards, Barend
Barend Gehrels, Geodan, Amsterdam.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk