Geometry Boost List: Re: [geometry] nsphere and views names

Subject: Re: [geometry] nsphere and views names
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-21 08:28:43

Hi,

Barend Gehrels wrote:
>>
>> Maybe something like this:
>>
>> geometry::view::as_centroid / as_center_point / as_center_point
>> geometry::view::as_ring
>> geometry::view::as_linestring
>>
>> ?
>
>
> Yes, this has been brought up earlier. It is certalinly useful to view a
> geometry as another geometry type,  and view::as_ring seems intuitive to
> me.
>
> view::as_centroid is maybe too specific, maybe just view::as_point ?
>

I think not only about viewing the whole geometry as the other one but 
also about accessing the geometry in a way the Concept isn't suitable 
for. E.g. we could also have view::as_min_corned and view::as_max_corner 
to 'work' on Box's points.

But maybe those shouldn't be views but some kind of accessors? Like 
access::as_center(circle), access::as_centroid(box), 
access::as_min_corner(box)? Probably view is a better name.

> Bruno did also have ideas about this.
>
> We already have the "view_as" structure and make_view_as function, which
> basically can do things like this. This is designed as:
>
> boost::geometry::make_view_as<point>(sphere), which obviously returns a
> point. This is not really worked out yet. See views/view_as
>

Having one class to do everything is reasonable but here the user must 
pass his point type so this view would probably be forced to store this 
point inside the view and convert sphere to it? This shouldn't be done 
in the case of views, well only in obvious cases. But in this case the 
data is there already and we can get lightweight view storing only a 
reference.

However make_xxx could be used however it doesn't fit well in mentioned 
context, i.e. view::make_as_ring(box). view::return_as_ring(box) maybe?

> The box_view is indeed the other way round, it sees a box as something
> else...
>
> So good this topic has been brought up again, thanks.
>
> See also my other mail about closeable_view, and reversible_view, but
> that is more viewing a Boost.Range like thing as another Boost.Range
> like thing, so not exactly the same.
>

Yes, the way how adaptors work correspond to our views. What do you 
think about adapting Boost.Range syntax? Not necessarily now and I'd be 
careful with it. Just a thought, e.g.:

view::as_polygon<Box> b = box | adaptor::as_polygon;

or aside from views:

box | adaptor::as_polygon | adaptor::transformed(make_rotation(mat))

And as_polygon might not convert box to polygon and store it inside but 
define its own iterator which do it on the fly. The same with 
transformed. So basically they could behave like Boost.Range adaptors.

Regards,
Adam