Re: [boost] preview of a template geometry library

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-02-01 07:33:23

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