Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2009-02-24 11:58:18

--------------------------------------------------
From: "Barend Gehrels" <barend_at_[hidden]>
Sent: Tuesday, February 24, 2009 7:29 AM
To: <boost_at_[hidden]>
Subject: [boost] [geometry] area, length, centroid, behavior

> I would like to hear the opinion of potential geometry users on the list 
> about the following.
>
> For the three geometries, point, linestring (= sequence of points), 
> polygon:
>
> What should the generic "area" algorithm return for point and linestring?
> - 0 (zero)
> - compiler error (so this function is not defined for them at all)
> - exception
> Personally I would feel for 0 (zero) because you can then request the 
> "area" in a generic collection, regardless of what is inside.

I think failing to compile would be the most reasonable. I cannot think of 
any reasonable use-case where one would want the area of a point, or a line. 
I suspect the most often encountered case would be that the user has made a 
logic-error. The same applies to volume (or any integral quantity which is a 
function of dimension). I would suggest that area would require a 2D concept 
and that the shape of the object be at minimum a 2-simplex (triangle.. 
possibly degenerate). Then volume would require a 3D concept and at minimum 
a 3-simplex (tetrahedron also possibly degenerate) and so forth. By assuming 
a value of 0 for the area of a point or line, you are saying that these 
represent a degenerate 2-simplex (even though these representations do not 
maintain the topology of a 2-simplex.) The only quibble I can see would be 
for calculating things like 'surface area' or 'perimeter length' which 
implies a dimensionally constrained integration on a higher dimension 
object. I think being more rigorous for these will give users a better 
experience than having higher abstraction.
>
> What should the generic "length" algorithm return for polygon?
> - 0 (zero)
> - its perimeter
> - compiler error
> - exception

I would not define 'length' for a polygon. Perimeter has a distinct meaning 
from length and so I think should the name of the function that calculates 
it. As for the length of a polyline/linestring, I think this falls in the 
same camp as the 'surface area'. These really describe breaking up the 
higher dimensional object into many lower dimensional objects, solving them 
piecemeal under their dimensional constraints and then aggregating the 
results. For these I don't know what would be best. My advice would be to 
err on the side of making sure the user knows what she's doing. I should 
take my own advice :D.

>
> What should the generic "centroid" algorithm return for point and 
> linestring?

The centroid of a collection of points is well defined. Perhaps this is the 
function you should provide? I would suggest having this separate from 
functions calculating the centroid of a solid.

> and for an invalid polygon (e.g. no points at all, or not closed)?
> - exception
> - return "false" (if centroid is passed as a reference parameter)
> - ? (we've not always the compiler error option here because points are 
> usually stored in a runtime collection)
>
> Thanks, Barend
>

HTH,

Brandon