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
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?
- 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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk