-------------------------------------------------- From: "Barend Gehrels" <barend@geodan.nl> Sent: Tuesday, February 24, 2009 7:29 AM To: <boost@lists.boost.org> 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