Re: [boost] Is there any interest in a template geometry library?

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-01-16 11:02:20

Phil,

> Phil Endecott wrote:
>   
> Barend Gehrels wrote:
>   
>> Is there any interest in a template geometry library?
>>     
>
> There certainly is.  My particular interest is in efficient containers 
> for points (and perhaps lines) with iterators over 2D ranges; have you 
> done anything like that?
>   
There are three kinds of iterators can be used in our library:
- you can use the standard std::for_each to iterate over the points of 
for example a linestring or a multi_point, or a part of a them (using 
begin() end()  or so) because it's all std:: container implementation here
- besides that the library supports a for_each_point which iterates over 
all points of a linestring, polygon, and all multi geometries
- furthermore the library supports a for_each_segment which iterates 
over all segments of the relevant geometries
I don't know if this answers your question?
> Some random thoughts:
>
> Of course you're aware of the GTL proposal from a group at Intel last 
> year.  Here is my recollection of a couple of aspects of that discussion:
>
> - It turned out that their implementation uses a cast from a base class 
> to a derived class, which works because the derived class has the same 
> layout as the base class in all known compilers.  This is a pragmatic 
> choice, but it's not the sort of thing that's going to be popular with 
> Boost people as the list discussions revealed.  Unfortunately, because 
> their library is complete and in use, they're too far down the road to 
> change something as fundamental as that.  When I read "We at Geodan are 
> developing our library since 1995", I was immediately worried that your 
> library would also turn out to have some unpopular feature at its core, 
> now impossible to change.  So letting us see the code ASAP is 
> definitely a good idea.
>   
I understand. Our complete library is from 1995 and is large. The 
geometry is only a part and that part had to be rewritten; that's done 
end 2007 and still in progress. It's redesigned from scratch, in that 
sense it is brand new. But some of the algorithms are copied and adapted 
from the 1995 one, in that sense the good parts are taken over. The new 
geometry part is regularly reapplied to (included in) the complete 
library (which is not completely rewritten and is not a boost candidate) 
but if adaptions are necessary, that is no problem.

Furthermore there are no casts, actually there is no real inheritance 
and there are no virtual methods; furthermore there are no calls to new 
or delete and hardly any exceptions thrown.
Code will be there next week.
> - A feature of GTL is that it can accommodate arbitrary point types by 
> means of suitable adapters.  I had mixed feelings about this.  On one 
> hand, this makes it possible to apply their algorithms to legacy data 
> structures.  On the other hand, I think that it would add an extra 
> layer of complexity for new users who have no legacy to worry about 
> (and library learning-curve steepness is something that I give a lot of 
> weight to).  Compare this to the standard library: using maps I often 
> find myself writing "first" and "second" when I'd prefer to be writing 
> "key" and "value" or "customer_number" and "address".  If std::map 
> could be adapted to work with arbitrary structs, rather than std::pair, 
> that would be a good thing.  So maybe we do need this extra layer.  
> Except that it might make coding the libraries more complex, and my 
> space-filling-curve point-set was at the limits of my C++ ability 
> already!  Indecision.
>   
I don't know the GTL details. However, in our case the geometries 
doesn't contain any data but x and y. If a user wants more, he can 
derive from our point type to include for example SRID or color or 
anything. Or he can implement his own point type. So I think it 
approaches your "arbitrary structs".
> Considering GTL, this library, GIL, and even CGAL, how much commonality 
> is there?  Are there shared concepts between all of these libraries?  
> Can we extract some common concepts or patterns from the different libraries?
>   
Will answer this briefly in the documentation, probably not completely. 
The answers on these questions are too extensive to give them here at 
this moment. However, it is interesting.
> Perhaps something that's also worth asking is whether Boost is the 
> right place for such a library.  Getting releases out has not been a 
> smooth process over the last couple of years, and I can't imagine that 
> adding more libraries makes it any easier.  Maybe Boost ought to focus 
> more on things that are close to the standard library, and let other 
> code find a home elsewhere.
>   
That's not for me to decide, however, personally I miss in boost things 
as point-in-polygon and distance, I think a geometry library is useful 
in boost.

Best regards, Barend Gehrels