Phil,
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.
Of course you can download and look at the sourcecode, no problem. It is stated like this because it is not yet open source, it is not yet submitted or accepted by boost and at no other open source site. Therefore I cannot state there that it is open source at this moment. However, for review purposes it is allowed to look in it. If this is not sufficient I can change the statement.
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.
I understand and I agree, for a linestring an iterator pair would be convenient sometimes. We could implement the linestring-specific algorithms as length or simplify like that. However, for polygons it usually doesn't make sense to run an algorithm on a part of a polygon. Centroid, area, or clipping is usually (always?) done on the whole thing. Therefore for linestrings it is also like this, to be consequent. However, this might be changed if wished, no problem.
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!)
OK.
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.
They work out-of-place, they deliver a copy. And indeed this might result in an identical one, I will consider to avoid that. Do you want to have a boolean returned or something like that? However, to me it would seem awkward to check each time if my result is in the source or in a copy. Besides that, in many algorithms you know (or even then don't know) that the algorithm resulted in the same output as the input after the process is completed. The copy is then ready, so in those cases it is not more efficient.
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?
The "within" algorithm is returns true if a point is completely inside because it is specified like that. The "touches" algorithm, not in the preview, returns true if a point is on a border of a polygon. Each point within the set you refer to is either within one polygon, either on the border of (indeed) two polygons then. You would need an algorithm which returns true if a point "touches" upward edges and otherwise false (+ horizontal case), for example, but that one is not in the OGC set and not planned by us (and you would have problems on the border of the set).
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?
I cannot answer these questions. But please look first at the source code, it is allowed. The documentation might not be perfect (or far from), also because I was asked to publish the code asap. So it is produced somewhat in a hurry by a non native speaker. However, there were positive voices as well. Best regards, barend -- ------------------------------------- Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands, www.geodan.nl