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.