Re: [boost] Preview 2 of a template Geometry Library

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.