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