
Boost : 
Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Brandon Kohn (blkohn_at_[hidden])
Date: 20090224 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 usecase 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
logicerror. 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 2simplex (triangle..
possibly degenerate). Then volume would require a 3D concept and at minimum
a 3simplex (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 2simplex (even though these representations do not
maintain the topology of a 2simplex.) 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk