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.