[GRASS-dev] 3D types

[Benjamin Ducke]

[sorry for reposting, I used the wrong subject header before] 

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 at 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 at 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. _______________________________________________ grass-dev mailing list grass-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev 


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