Geometry Boost List: Re: [geometry] generic for_each and num proposal

Subject: Re: [geometry] generic for_each and num proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-07-28 13:54:05

Hi Michael,

On 26-7-2013 23:54, Michael Winkelmann wrote:
> Hi all,
>
> I've played around a lot with boost::geometry and find the 
> for_each_point and for_each_segment algorithm very useful.
> However, I think of a more generic approach which will makes most 
> sense together with C++ lambdas:
>
> Let's assume we have a for_each template with the following type 
> definitions:
>
> template<class SubGeometry, class Geometry, class Functor>
> for_each(Geometry& g, Functor f) { ... }
>
> typedef boost::geometry::model::d2::point_xy<double> point;
> typedef boost::geometry::model::polygon<point> polygon;
> typedef boost::geometry::model::ring<point> ring;
> typedef boost::geometry::model::segment<point> segment;
>
> E.g., if you have a polygon and want to iterate over each ring:
> polygon myPolygon(...);
> for_each<ring>(myPolygon,[&](const ring& r)
> {
>     /* code here */
> });
>
> Or, if you want to iterate over each segment in a ring:
> ring myRing(...);
> for_each<segment>(myRing[&](const segment& s)
> {
>     /* code here */
> });
>
> For the num_points algorithm, there might be  an analogous generic 
> definition:
>
> template<class SubGeometry, class Geometry>
> size_t num(const Geometry& _g) { ... }
>
> size_t a = num<ring>(myPolygon); // Returns number of rings in polygon
> size_t b = num<segment>(myRing); // Returns number of segments in ring
> size_t c = num<polygon>(myPolygon); // Should return 1
>
> I'd be glad to hear your opinions.
>

I like it!

Basically the for_each_point and for_each_segment should already work 
with lambda's. So that is not the point here. But for_each<> instead of 
for_each_{named thing}  is definitely an improvement.

About num_points, yes, that is also good but... num_points and 
num_interior_rings are prescribed by OGC (which we follow). If we leave 
that (we could), then I would propose "size" instead, like STL does. The 
num_interior_ring does have a tweak - you don't really know this... You 
might say it is num<rings> - 1, but in case of multi-polygons that is 
not valid.

For num<polygon>, this is 1 for a Polygon concept, but not for a 
MultiPolygon concept.

Regards, Barend