Re: [boost] Preview 2 of a template Geometry Library

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-03-26 16:36:03

Bruno wrote:
> 
> >  I understand what the original poster was trying to convey, and
your
> opinion is valid,
> >  but they both need much more clarification than saying things
should be
> interchangeable.
> 
> Indeed, things have to be clear on that point, and I'm a bit confused
> about what really constitutes the concept of a point. What I have
> understood until now is that a class is the point if it exposes:
> * the value<>() getter and setter
> * coordinate_type
> * coordinate_count
> 
> and that besides this, the .x and .y of the point_xy class were just
> some syntactic helpers provided for an easier external use of this
> class. But I see that almost all the algorithms use .x and .y, which
> means that they won't work with the basic concept I just described.
> Shouldn't all those algorithms be implemented in terms of value<>()
> accesses ?
> 
> Some headers that use .x and .y:
> area.hpp
> strategies_point_xy.hpp
> centroid.hpp
> correct.hpp
> envelope.hpp
> intersection_linestring.hpp
> intersection_segment.hpp
> 
> Bruno
[John Femiani] 

This is why I would like to see concepts spelled out like this:
http://www.boost.org/libs/concept_check/reference.htm#basic-concepts
as is done by other boost libraries which I like, such as gil
http://stlab.adobe.com/gil/html/index.html,  BGL
http://www.boost.org/libs/graph/doc/graph_concepts.html , fusion, and
others.  They all clearly specify their concepts using the SGI style and
provide concept checking classes.  To me that makes them easy to
understand.

IMHO the core need from a point library is the concepts, not the models,
because there are so many different well-tuned geometry libraries that
exist, and the idea is that boost _algorithms_ work on any "point",
rather than that boost have a great point class (those are easy). 

Also, I already disagree about the idea that a point should have
coordinates. CoordinatesConcept should be part of a separate concept. Of
course a useful point class will model both the coordinates and the
point concept. To me a point should really support transform, scale,
rotate, shear, and distance operations as free functions (maybe more). 

I don't know how to handle the idea of a 'space' or a 'kernel'. 

BTW, I came across lib2geom the other day and they seem to be using
concepts:
http://lib2geom.svn.sourceforge.net/viewvc/lib2geom/lib2geom/trunk/src/c
oncepts.h?view=markup