Re: [boost] Preview 4 of the Generic Geometry Library (ggl)

Subject: Re: [boost] Preview 4 of the Generic Geometry Library (ggl)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-02-19 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 concept-centric 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?