
Boost : 
Subject: Re: [boost] Preview 4 of the Generic Geometry Library (ggl)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 20090219 07:56:23
Barend Gehrels wrote:
> The library is really generic now, concepts
> are everywhere, as requested by the list before. It can take any
> std::vector or range, as requested by this list.
That's certainly very good, isn't it?
So you can do retroactive modeling and everything.
> It is coordinate system
> agnostic and dimension agnostic, as requested by the list.
I wonder how it works. I hope the algorithms can still be written
generically, and don't have to be written independently for every
coordinate system.
I also hope you didn't force yourself to too much agnosticism just
because it was requested on the list.
People request lots ;).
> How is
> everything now? Let's put it in another way, is there any interest in
> such a geometry library?
I don't have the time to really analyze it for the moment, but it seems
to be taking shape.
Just a few comments from a quick look:
There seems to be a few inconsistencies in the documentation, Ring says
it checks the linestring concept, for example.
Also, what a geometry is should be in the documentation of its concept,
not of its model (the model is the implementation of a concept).
Of course, the documentation isn't really conceptcentric at the moment.
The documentation of geometries isn't very clear, by the way. For
example, what's an nsphere?
Is it the set of points which are at an equal distance of another point,
the center? (what a(n n)sphere really is)
Is it the set of points which are at an equal or inferior distance of
the center? (typically known as a ball)
I would recommend clearly defining every geometry to prevent
ambiguities, in terms of set of points maybe, rather than referring to a
name which may have various meanings.
In the same sort of thing, a polygon is not just the set of points which
are on its border, it's all the points that are within, too.
The name "ring" lets me think it's just the border.
Being clear about what the geometry is necessary for the overlap algorithm.
Indeed, inside is not part of overlap, obviously. Unless the inside in
question is part of one of the geometries.
A small circle within a bigger circle is not overlap. But a small circle
within a bigger disk is.
There are various solutions to address the issue of distinguishing
between spheres and balls and the like: you may add new types or adapt
your algorithms to take into account inside/outside etc.
I find new types (or rather, concepts) to be more elegant, but that also
makes the library more bloated.
I also just noticed the performance section. It doesn't really tell what
the other libraries are. And since GGL is so much more efficient (by an
impressive margin, actually), I recommend adding other libraries to the
benchmark: why not CGAL? That one should be a much tougher competitor.
How is the new selected algorithm much different from distance? It seems
it's either distance or within that is used, depending on the geometry.
Is there a use for this algorithm? It just feels kind of weird to me.
Is concept refinement implemented? Is a Ring also a ConstRing and a
ConstPolygon?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk