Geometry Boost List: [ggl] Clipping/Intersecting efficiency

Subject: [ggl] Clipping/Intersecting efficiency
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-05-29 04:12:28

Hi Chris,

Welcome to the list!

> Profiling my application (Merkaartor, which uses, notably, ggl to do 
> linestring clipping), I came to realize that clipping takes about 70% 
> of the time it takes to draw a frame!
That is too bad indeed.
>
> 2 reasons for that:
>
>  1) My "linestrings" are vectors of POINTERS to points.
> I didn't find a way to use pointers as valid point_2D, so I have to 
> recreate a linestring_2D before intersecting -> malloc -> poor 
> performance.
> Is there a way to use a std::vector<point*> as a linestring?

That must be possible, using traits classes. You have to register a 
point* as a valid point, implementing the traits classes with access 
methods to get and set the coordinates. c01_custom_point_example.cpp is 
an example, but there are registration macro's used, probably you cannot 
use those. So then it will be something like (from a sample with a 3D 
point "my_color" with fields red,green,blue):

namespace ggl { namespace traits {

template<> struct tag<my_color>
{ typedef point_tag type; };

template<> struct coordinate_type<my_color>
{ typedef double type; };

template<> struct coordinate_system<my_color>
{ typedef cs::cartesian type; };

template<> struct dimension<my_color>
    : boost::mpl::int_<3> {};
template<>
struct access<my_color>
{
    template <std::size_t I>
    static double get(const my_color& p)
    {
        return I == 0 ? p.red : I == 1 ? p.green : p.blue;
        // Or implement an accessor with specializations
    }

    template <int I>
    static void set(my_color& p, const double& value)
    {
        // Or (better) implement an accessor with specializations
        if (I == 0) p.red = value;
        else if (I == 1) p.green = value;
        else if (I == 2) p.blue = value;
    }

};

}} // namespace ggl::traits

(If you have your sources from boost, replace ggl:: by geometry::, this 
is from the new version).
If you need help with it I can create another sample with a point* or a 
template-wrapper around a point*

> 2) intersecting uses outputstream to store its results. This again 
> means malloc -> poor performances.
> Would it be possible to have an option to use a callback function 
> returning the ordered result?
The output iterator is the most generic option. The first version 
outputted to a multi-line, but now programmers can decide themselves 
what to do with it (multi-line, console, etc). However, it internally 
has to append points to lines. It is probably also possible to 
specialize also that one for specific situations -> this will probably 
have the same effect as a callback.

>
> Other programming practice suggestions are obviously welcome.
Having the point* (or a template-wrapper around it) registered as a 
point, and a vector<point*> as a linestring, you should be able to call 
all ggl-algorithms more naturally.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090529/038dccf7/attachment.html