Re: [boost] preview of a template geometry library

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-01-31 16:54:32

Barend Gehrels wrote:
> Herewith the URL to the preview of Geodan's Geometry Library, including 
> documentation and some examples.

Hi Barend,

A few initial comments follow.

Quote from http://geometrylibrary.geodan.nl/geometry.html :

    This library may be used for review purposes only. It is not yet
    published. If submitted and accepted, this library will follow
    the Boost Software License.

What do other people think of this?  Is it OK to say that the code is 
not available at all, unless it is accepted?  What are the precedents?  
Normally, if a library is rejected then people who wanted to use it 
still have the version submitted for review available to them.  A 
review manager who rejected this library would prevent that sort of 
use, and that could skew their decision.  I'm not going to look at the 
code until this is resolved (my lawyer wouldn't let me); these comments 
are based on the documentation.

You say that a linestring is a vector<point>.  Since your algorithms 
are header-only, you should instead say that a a linestring is a 
random-access sequence<point>, bidirectional sequence<point>, or 
whatever.  In the same vein, taking a (begin,end] iterator-pair rather 
than the whole container would be more standard-library-like.  Of 
course that's more verbose, but apparently Ranges can fix that.

Using existing naming conventions has obvious advantages and 
disadvantages.  From what I've seen, the OGC names are not too bad.  
(Compared to the XML DOM, for example, which I dislike!)

Do things like your clipping and simplification algorithms work 
in-place or out-of-place, or both?  I can imagine that both of these 
examples will often return a result identical to the input, in typical 
usage; avoiding a copy in that case would be worthwhile.

Consider a set of polygons that tile an area.  It would sometimes be 
useful if all points were 'within' exactly one of the polygons, i.e. 
boundary points fall one side or the other, but not both or neither.  
This is straightforward for rectangular tiles but more difficult in 
general (even with integer coordinates).  Your 'within' implementation 
allows boundary points to fall between tiles, by design; is this really 
the most useful choice?

Where should we go with this?  I support getting geometry into Boost.  
But rather than a library like this, which is really not very 
comprehensive, shouldn't we instead prepare a set of concepts against 
which people can submit algorithms?

Regards,  Phil.