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.