Boost logo

Geometry :

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


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

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.


Geometry list run by mateusz at