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

Markus Metz wrote:

I have recently imported shapefiles from the SRTM waterbody database
which are 3D, but correct areas were built with the current 2D topology
algorithms. In this particular case, 3D topology is not needed to
preserve z coordinates. In general, z-values could be added to any 2D
vector with areas and the current 2D topology building procedures could
still work. An easy way to achieve this is to use 2D routines for
boundaries and 3D routines for edges. Just an idea.

Assigning centroids using a 2D placement algorithm works as long as
the 3D polygons have some area in the X-Y plane. That is certainly
true for the surfaces of water bodies. But there are some extreme
cases ("catenas", vertical cross-sections) where this will fail.
Also, for automated labeling, the centroid position will not be
ideal.

centroids can be 3D, so for faces just put one in the middle of the
plane.

See above: We need a centroid placing algorithm that works in a plane
with arbitrary orientation in 3D space (should not be too hard
to abstract from the X-Y plane case).

(I'm assuming that faces have to be flat, but maybe that doesn't have to
be. what happens if the boundary/edge polyline defining it is 3D like a
bent coat-hanger? why limit ourselves to 3D-TINs?)

Faces are polygons and thus by definition all their vertices lie in one
plane. Departing from that premise leads to very complex geometries.
I do not know of any software that implements those. It is easier
to built such complex shapes as combinations of simple faces like you
would build a complex polyline/curve as a combination of line segments.

AFAIAC, all that is open for discussion. All vector features, also
boundaries, can be 3D i.e. have z-coordinates but currently 3D topology
is not supported because not present in the vector libs. I don't know if
faces have to be flat, if there are algorithms out there that support
non-flat faces we could/should use them. Any 3D geometry expert out
there? In any case, full 3D support in g7 would be really cool. I'm
starting to search geometry libraries for 3D algorithms but first 3D
algorithms are scarce and second these geometry libraries including GEOS
can not always deal with "real-life" vector objects, they are made for
ideal vector objects.

While I am certainly not a 3D graphics or geometry expert, I have
read up on the topic of 3D topology in the past. It is very complex
and every application I know of only implements a small subset of
possible topological constraints, just good enough to fit the purpose.
That's why I believe keeping it simple and building on simple, planar
faces as a basis for more complex objects is the most promising path.

I am in favor of extending the GV_AREA struct (see my previous email)
with a 3D variant that uses simple faces instead of lines. This would be
completely transparent to the user and GRASS would take care of
using the right representation if the area is 3D.

As far as I can think right now, what we need then is:

1) a way to place 3D centroids (see above)
2) a way to break up complex polygons into sets of 3D triangles (easy)
3) perhaps a way to check for overlap of 3D areas
4) tools to clean 3D topology (hard? maybe not even necessary)

Ben

Markus M

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

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

----- "Hamish" <hamish_b@yahoo.com> wrote:

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)

Yes. That's what I was thinking, too.

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.

Exactly.

> 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)

Well, if you fit an X-Y plane anywhere through your lake, at any
elevation, the lake's cutting plane should have an area > 0.

> 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?

None. If we have a 3D centroid placing algorithm.

> 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

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.