Geometry Boost List: [ggl] boost geometry rtree

Subject: [ggl] boost geometry rtree
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-07-19 06:17:01

Barend Gehrels wrote:
>
>
>> Adam Wulkiewicz wrote:
>>> Adam Wulkiewicz wrote:
>>>>> OK, I will look/ask for this in more detail. If anyone on this list
>>>>> know the very right term, it is welcome. So the question is:
>>>>>
>>>>> "content" means: length-in-1-D, area-in-2-D, volume-in-3-D
>>>>> "XXX" means: perimeter-in-2-D, area-in-3-D
>>>>>
>>>>> where "XXX" might be margin. The term "content" is quite difficult
>>>>> to Google, by the way.
>>>>
>>>> Other possibility is to use straightforward hypervolume and
>>>> hypersurface. They're both at MathWorld's pages I've mentioned and
>>>> to be honest I've found pages googling these terms. Other ideas?
>>>
>>> Since mathematical names like hypervolume, hypersurface and hyperarea
>>> may be confusing and there isn't probably any other name describing it
>>> we may just make something up. Ideas:
>>>
>>> - some word corresponding to 'content' - wrapping, packing, packaging
>>> etc.
>>>
>>> - border, border_zone, XXX_zone
>>>
>>> - mantle (I like this, and then content may be replaced by core but
>>> this is a lot more confusing)
>>>
>>> - coat, jacket
>>>
>>> Btw I like the 'margin' term, in the case of 2d it associates to the
>>> part of the area around the object, not the perimeter but it fits more
>>> or less.
>>
>> My preference would be to use area and perimeter for 2D; volume and surface_area for 3D and hypervolume and hypersurface for N-D.  I believe this issue was discussed in the boost list quite a while ago.  We can easily wrap hypersurface and hypervolume with functions that have more intuitive names for the object type passed in and check that it conforms to the right number of dimensions at compile time.
>
> Sure, area is there and will stay, volume will be added as well once. But there is also the need to have a dimension agnostic measure, and that is where we look for. So we are looking for the more intuitive names of the wrapping hyper functions.
>
> I will ask this today or tomorrow to a collegue, therefore did not answer yet on Adam's suggestions,

I'd also prefere hypervolume and hypersurface names. In addition to 
this, the area and volume functions should be N-D as well. area() (or 
better surface(), it would be compatible with hypersurface) should work 
for N > 1 and volume() should work for N > 2. 3D objects has a surface 
of 2D faces which area may be calculated (it is in fact our 
hypersurface's area). 4D objects have a 2D surface of faces and a volume 
of 3D cells (in analogy to faces in 3D) which is on the other hand our 
hypersurface's volume. So surface and volume has the same units for all 
dimensions, hyper-functions has variable units.

My preference would be to have functions: ND-area/surface/surface_area, 
ND-volume, ND-hypersurface, ND-hypervolume. Eventualy area could be 
defined for 2D only and surface and hypersurface for ND like there is 
perimeter for 2D only and ND hypersurface.

Where:
2D-perimeter = 2D-hypersurface
2D-area = 2D-surface = 2D-hypervolume
3D-surface = 3D-hypersurface
3D-volume = 3D-hypervolume
4D-volume = 4D-hypersurface

Then only ND hypersurface and hypervolume could be implemented as 
Lucanus has written and used in other functions. But if we want to 
calculate the surface area of an object in dimension greather than 3 
(e.g. surface of the 4D object) or volume of the object in dimension 
greather than 4 (e.g. volume of the 5D object) then surface() and 
volume() functions must be implemented separately, for ND.

Regards,
Adam