Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-11-11 15:27:21

Mateusz Loskot wrote:
> The layout of GGL source tree follows Boost convention.
> In spite of that, you are right, users will likely have to update
> their GGL-based source code

What I mean is that a file like cartesian2d.hpp which currently reads more or less

// Predeclare common Cartesian 2D points for convenience

#include <ggl/geometries/geometries.hpp>

namespace ggl
{

typedef point_xy<double, cs::cartesian> point_2d;
typedef linestring<point_2d> linestring_2d;
typedef linear_ring<point_2d> ring_2d;
typedef polygon<point_2d> polygon_2d;
typedef box<point_2d> box_2d;
typedef segment<point_2d> segment_2d;

} // namespace ggl

must be changed to 

// Predeclare common Cartesian 2D points for convenience

#include <boost/ggl/geometries/geometries.hpp>

namespace boost { namespace ggl {

typedef point_xy<double, cs::cartesian> point_2d;
typedef linestring<point_2d> linestring_2d;
typedef linear_ring<point_2d> ring_2d;
typedef polygon<point_2d> polygon_2d;
typedef box<point_2d> box_2d;
typedef segment<point_2d> segment_2d;

} } // namespace boost::ggl

before inclusion in a boost release. You are right that the user can explicitly add boost to his include path and add a global "use namespace boost;", and then has at least a chance that he doesn't need to change anything else.

If you prefer the GIL style, you could also change 

#include <ggl/geometries/geometries.hpp>

to 

#include "geometries.hpp"

> > GGL on the other hand provides just one point, linestring, 
> > linear_ring, polygon, box and segment class template, because the 
> > representation isn't really the challenge in the context of geometry.
>
> Not really. GGL proposes some definitions of types for basic
> fundamental geometries. However, user does not have too stick to them.
> Moreover, it is expected that users may want to not to touch
> these (pre-)defined types but define their own types.

Are you sure? Even so I was vaguely aware that you haven't fully understood what I meant by representation, I still took a look at "linestring_concept.hpp" to check whether you enforce a certain representation to the user. Now I'm totally confused, because "geometries/adapted/std_as_linestring.hpp" registers std::line<P> as a linestring, but the following concept requirement for linestring seem to rule out std::list<p>:

BOOST_CONCEPT_ASSERT( (boost::RandomAccessRangeConcept<Geometry>) );

Now I should try to explain what I mean by a representation. GIL gives the example that the RGB values might be saved interleaved as

RGB RGB RGB 

or as separate arrays

RRR GGG BBB

and that both representations might have advantages and disadvantages for different use cases. One of the goals of GIL is to allow writing algorithms that will work on both (and most other sensible) representations.

So in the context of GGL, we could think about a polygonal domain (roughly equivalent to the multi polygon concept) and its different representations. For a use case where we quickly want to answer the question which points in a given list of random points are inside the polygonal domain, another representation is optimal than in the case where we want to compute the intersection of two polygonal domains (similar to std::set and std::vector). However, generalizing over this type of generic representations is not the goal of ggl, and it would probably be an inappropriate goal for any 2d focused geometry library.

Yes, the user of GGL can use his own types for the basic fundamental geometries, but these types should better use the same underlying representation as the types proposed by GGL itself do. As I said before, this is perfectly fine, because this is probably exactly what the user of the library wants. (Well, the user would probably also be happy to have access to different representations of polygonal domains for different use cases, but he would probably have no problem if writing algorithms that will work on different representations will not be possible.)

Regards,
Thomas