Boost logo

Boost :

Subject: Re: [boost] [GGL] Can't seem to use equals on multi_polygons
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-01-21 10:39:43


Hi Kef,

>> Intersections are enhanced in that new version. However, they should
>> still be oriented clockwise in this version (the definitions from your
>> first samples are counter-clockwise (so it was useful them being there
>> :-) ).
>
> Wait... my coordinates were counter-clockwise? I'm confused... are
> they supposed to be specified in (y, x) order instead of (x, y)? I
> assumed they were (x, y), in which case the coordinates would be
> clockwise: right, down, left, up.
It has to be (x,y).

Your first sample listed:
> {0, 0},
> {1, 0},
> {1, 1},
> {0, 1},
> {0, 0}
So this is lower-left, lower-right, upper-right, upper-left, lower-left.
So counter-clockwise.

There is a function to correct it (boost::geometry::correct) so no problem.

>
>
>> Is GGL running fine using CodeWarrior?
>
> For the most part, yes. There were a couple of hacks I had to make:
> * I had to change cartesian_distance::operator<< to use a plain ol'
> ostream instead of a basic_ostream<Char, Traits>. CodeWarrior didn't
> like the use of a template there, apparently. Using a plain ostream is
> fine for the purposes of my program -- in fact, the final program will
> use no streams at all. (Somebody on IRC suggested an alternative
> solution that might allow for the template, but I haven't tried it yet.)
>
> * I applied the same hack to dsv_manipulator::operator<<.
OK, thanks. AFAIK this was a normal and correct usage of templates
there. So we can probably use defines there, for CW. Or that IRC
suggestion (which I don't have).

>
> There is also another problem I've just discovered:
> * get_not_intersecting_holes<polygon_tag>::apply (from
> ggl/algorithms/overlay/assemble.hpp) does not compile correctly. I
> thought maybe the code I'm using doesn't need it anyway, but I tested
> it and it seems I thought wrong. This is the part it chokes on:
>
> typename boost::range_const_iterator
> <
> typename interior_type<Polygon>::type
> >::type rit = boost::begin(interior_rings(polygon));
> std::vector<bool>::const_iterator iit =
> boost::begin(intersecting);
>
>
> This yields this error message:
>
> Error : illegal implicit conversion from
> 'std::__bit_iterator<Metrowerks::__bitvec_deleter<std::allocator<bool>>,
> false>' to
> 'std::__convert_iterator<std::__implicit_convert<const bool *,
> std::__bit_iterator<Metrowerks::__bitvec_deleter<std::allocator<bool>>,
> true>>>'
So it seems not to like the std::vector<bool>. I just checked
assemble.hpp, it has been revised. The std::vector<bool> is removed already.
If you are using union's, you are indeed using assemble, behind the screens.

Regards, Barend


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk