Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-10-14 15:13:37

Barend Gehrels wrote:
> Dear list,
> 
> Herewith the URL to the third preview of our Geometry Library, including 
> documentation and examples.

Here are a few comments from a short read, then.

Let's start with naming:

- The names of the geometric objects isn't dimension agnostic, which 
might or might not be a problem. A circle is a circle in 2D, but a 
sphere in 3D. A line, however, is always a line. Same for segment  and 
polygon (and all yet-to-be-implemented objects which are polygons).
I think naming should try to differentiate objects that stay what they 
are when dimension varies or that evolve with that dimension. Either 
way, the name convention should be clearly explained in the documentation.

- Also, while most names are 2D-centric, "box" is 3D-centric. This seems 
fairly inconsistent.
Or maybe it's just me and box is actually dimension agnostic.

- Still about "box", it is really an axis-aligned (whatever that means 
in non-cartesian geometries) hyperrectangle.
Since "box" can not contain an arbitrary box, maybe it should be called 
minmaxbox or aabox or whatever.

- envelope calculates the minimum bounding axis-aligned hyperrectangle 
for an object.
It might also be desirable to have a way to calculate the minimum 
bounding hyperrectangle (non necessary axis-aligned) or the minimum 
bounding sphere. What names would those algorithms have if envelope is 
reserved for AABHR?

Objects:
- Why can objects be default-constructible?
- Modeling sequences of polygons as iterator pairs seems an annoyance to 
me, ranges are much prettier to handle since one variable is thus 
sufficient to represent one object (while two are required for iterators).

Algorithms:
- Algorithms should be overloaded to handle all geometric objects. I 
assume the reason it wasn't done is simply because of time to do so.
Also, within/intersection/etc. are not symmetric (in some cases there is 
an overload for alg(a, b) but not alg(b, a))
- why isn't envelope returning in result rather than taking a reference?
- Why are intersection_segment arguments template parameters instead of 
segment, why is it not simply an intersection overload and why does it 
return something different than intersection?
Maybe the design of the generic intersection should be extended so that 
it can work with segments rather than segments be made a special case.
In the case of segments, it either generates nothing, a segment or a 
point. A segment can represent a point, so the output might as well be a 
segment or nothing. Then the result can be checked to see whether it's a 
point or not. So I don't see why it needs special treatment.
- An overlap algorithm, that would be equivalent to testing 
not_empty(intersection) || within, would probably be interesting, 
especially since it is very useful for collision detection or spatial 
indexing. It can obviously be much faster than performing intersection 
and within calls.
- centroid says it throws an exception if the polygon does not contain 
any point. But how can a polygon not contain any points!?
The constructor of a polygon should force it to have at least one point.