[GRASS-dev] grass-dev <grass-dev@lists.osgeo.org>

[Hamish]

Ben:
> Assigning centroids using a 2D placement algorithm works as long as
> the 3D polygons have some area in the X-Y plane.

So, make the placement algorithm 3D. If it is a simple plane it is
just a little math to find the z value. "Just" rotate the plane, find
your centroid point in 2D, then reverse the plane rotation back into
x-y space.   (ok, lat/lon polar coords is a slightly curlier problem)

Assuming that the centroid type can store a 3D point, it should be fine.

On your 2D plan-view display monitor it would appear as a point on
a line, but as soon as you put in a 3D renderer you'd see it as a
point in the middle of the plane.

> That is certainly true for the surfaces of water bodies.

I'm not sure I understand that. You mean like perched lakes?
ie horizontal area floating in 3D space with a constant elevation?
(& water bodies are never truly flat, with wonderful consequences,
but that's completely off-topic)


> But there are some extreme cases ("catenas", vertical cross-sections)
> where this will fail.

As long as the centroid placement calc's the z value for the centroid,
and we stick with plane geometry for faces, besides a little coding
what's the problem?


> Also, for automated labeling, the centroid position will not be
> ideal. 

Centroids are not label positions and the should not be expected to
be used as such. It should be up to the S.A. (or whatever) rendering
code to decide how to place the label within the area wherever it
looks the best.


Hamish