Geometry Boost List: Re: [geometry] one more variation to "transform"/"convert"/"for_each_point"

Subject: Re: [geometry] one more variation to "transform"/"convert"/"for_each_point"
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-02-16 09:00:04

Hi,

On 16-2-2012 11:45, Mateusz Loskot wrote:
> On 16 February 2012 09:44, Bruno Lalande<bruno.lalande_at_[hidden]>  wrote:
>> Hi,
>>
>> Actually I was wondering if we shouldn't rather just provide a
>> "geometry_point_iterator" and a "geometry_segment_iterator" (implemented for
>> the geometries for which it makes sense). for_each_point is nothing more
>> than a std::for_each with a different iteration, and the transform_points
>> requested here is also just a std::transform with different iteration.
>>
>> MyPoly p;
>> auto points boost::geometry::point_range(p); // this returns a pair of
>> geometry_point_iterator or something along those lines
>> std::for_each(p, do_something);
>> std::transform(p, transformation, output);
>> // and any other std algorithm....
> I like Bruno's suggestion to exploit most of flexibility of the
> iterator concept.
>
> AFAIR, there was segment iterator at some point, though it would need
> optimisations.
>

I like the geometry_point_iterator too, it is a good idea. We should 
once create it (and also the segment iterator). This has indeed similar 
behaviour as foreach.

However, I don't think it offers what Volker described:

> I want to copy one (multi-)polygon to another while applying a 
> transform operator to its points. In particular, the result point type 
> of the transformation is different from the input point type. See this 
> code for an illustration:

With such an iterator alone you cannot achieve this. Unless you have 
also information when one polygon stops and another starts, when an 
interior ring stops and another starts, etc. But that is information you 
normally don't have for iterators.

However, the transform that we already have does implement such a thing. 
But it uses our "strategy model", which is not compatible with the 
standard functor behaviour. An option would be to add standard functors 
as an additional variant.

Regards, Barend