Re: [boost] [GGL] Can't seem to use equals on multi_polygons

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