Boost logo

Geometry :

Subject: Re: [geometry] nsphere and views names
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-23 17:18:40

2013/6/23 Barend Gehrels <barend_at_[hidden]>

> On 23-6-2013 19:03, Adam Wulkiewicz wrote:
> View preferably would store reference and provide needed data without
> conversion. And if someone wanted to convert the geometry because he want
> to reuse it somehow, he probably should use other method than view.
> view::as_centroid for sphere would just access center's coordinates using
> get<>(), for box it could calculate it on the fly using min and max
> coordinate, all without the conversion, and storing of additional Point.
> OK I understand that now. That needs an additional type (e.g.
> centroid_of_box) which calculates the x and y (and z) each time it is
> accessed. I don't know if I would really prefer that above a one-time
> calculation and extra storage of only one point...
In my scenario the view::as_centroid would be registered as Point.
Furthermore there should be no extra Point storage.
The view itself would take base Geometry and figure out which Point type to
mimic or take it as separate parameter. E.g. for Box this would be:

// or
as_centroid<Point, Box>


get<Dim>() would be defined as:

get<min_corner, Dim>(m_boxref) + (get<max_corner,
Dim>(m_boxref)-get<min_corner, Dim>(m_boxref)) / 2

> The same is true with envelope, e.g. envelope's min and max corners for
> Sphere, Point, even for Polygons could be calculated on the fly, there is
> no need to create additional Box, especially for Points.
> Thanks for the clarifications. I understand it now but would never use
> that - way to inefficient. Is there really need for this?
It depends, e.g. if there were an algorithm which would at first choose the
dimension somehow and then calculate something using the centroid, there
would be no need to calculate this centroid for other dimensions than the
one you've choosen.

But the truth is that I just wanted to access Sphere's center as Point, not
by using concept. The rest of this proposal is generalization for other

> As for bounds(). I'm using this kind of function in the Index. It is a
> generalization of envelope() and can calculate bounding objects of
> arbitrary type, e.g. bounding box or sphere.
> The envelope does that too (calculating bounding objects of arbitrary
> type) - what is exactly the difference?
Hmm, I thought it's only able to return Box. So there is no difference.


Geometry list run by mateusz at