Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-05-31 18:42:57
On 31-5-2013 23:28, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>>> Indexes names are slightly different and of course may be changed. For
>>> now it's like this:
>>> bg::get<bg::center_point, 0>(b);
>>> bg::get<bg::center_point, 1>(b);
>>> bg::get<bg::radius_value, 0>(b);
>>> There is one problem though. get() and set() assume that the type of
>>> returned value is always coordinate_type. So radius type will be
>>> converted if it's different.
>> Yeah, that is true. I realized that also at that time. The get<Index,
>> Dimension> was created for a box and after that reused for the nsphere
>> By the way, I did not yet react on that, but nsphere was the outcome of
>> an intensive discussion about the naming of such a thing...
>> OK, one solution is to make an explicit traits class for this. So not
>> just bg::get but get_radius, or something like that.
>> We also have to take into account the ellipse (2 axis) and ellipsoid (3
>> axis) or a higher dimensional shape. So Radius might have a dimension.
>> However, your proposal supports that.
>> And it might not be axis aligned... (we then go further than our box,
>> which is axis aligned).
> Yes, I saw how nsphere is implemented and accessed. I find it
> nonintuitive because N-th radius is returned by get_radius<N>() and
> N-th center point coordinate is returned by get<N>(). Other geometries
> which contain some points like box or segment uses indexed access,
> e.g. get<0, N>(). I feel that it would be more suitable for
> nsphere/ball too.
I did not look it up when I wrote my previous reply, but apparently the
original nsphere already has what I suggested...
OK, to be honest I find a separate function much more intuitive. bg::get
returns a coordinate. But a radius is not a coordinate. So that is why
we took a different function there, and it makes sense. It feels strange
to me to return a coordinate (the center) and a length-measurement (the
radius) using one function, just by changing the index. And yes, it
gives problems too for different coordinate type / radius type (these
should also differ...)
For box/segment, get is indeed indexed, but in both cases it returns
real coordinates and not another geometry property.
Geometry list run by mateusz at loskot.net