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