[GRASS-dev] 3D types

Benjamin Ducke benjamin.ducke at oxfordarch.co.uk
Tue Sep 15 13:18:30 EDT 2009


This one is tricky.

Of course, we could also be asking ourselves why we
need kernels if we have 3D centroids and then go on
to ask why we need centroids if we have points.
I think the answer is that every one of these entities
has its own type because it is meant to take on a very
specific role in the topological model. Having different
types simplifies that model and its implementation, as
well as import/export to/from other GIS data formats.

The trouble with the face type (which in the current
implementation is a polygon and thus planar)
is that outside the GRASS world, a "face" is taken to
be a simple, convex polygon without any holes. 
It is really a primitive type and the 
3D equivalent of a 2D line, not of a 2D area. GRASS does
not currently keep anyone from creating concave faces,
but external software (e.g. ParaView) will have trouble
rendering them ("bleeding"). So keeping faces simple
is, in my opinion, a good idea. More complex shapes can
be modeled by decomposing them into simple triangles.
This is what 3D modelers usually do and this also allows
having holes in the shapes. The problem of course is where
to attach the attribute record for a 3D polygon that consists
of many face primitives. For this, we need a centroid and
then we have the 3D area equivalent of a 2D area. 

So I think what we should do is implement 3D areas as
3D planar triangulations plus a 3D centroid in the same
plane.

In the case of volumes, we should talk about "surfaces"
instead of "boundaries", as they are actually a different
topological entity. While faces must always be planar,
this restriction is dropped for volumes.

Btw. other GIS, such as ArcGIS, also do not handle complex
3D polygons. Try creating a polygon with a hole in 2D, 
then rotate  it around the X or Y axis, and load that into
ArcScene: while it can handle concave shapes, any holes
will not display correctly. AutoCAD MAP will simply drop
complex 3D polygons on output to a shapefile.

As we are pushing the limits of current GIS theory here,
we should probably ask ourselves the question: what phenomena
do we want to model in 3D space and what representations
and topological models do we need for this? Simple 3D faces
can go a long way for visualization but that's about it.

It would be invaluable to have Radim's input on this...

Ben

Hamish wrote:
> why should the boundary type be limited to 2D?
> 
> if boundary is allowed to be 3D there is no need for some new "edge"
> feature type. I understand that it may make the topology code trickier,
> but adding the new type seems redundant to me.
> 
> as for the kernel, it seems ok that it would be the center of a volume.
> 
> centroids can be 3D, so for faces just put one in the middle of the plane.
> (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?)
> 
> 
> Hamish
> _______________________________________________
> 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.



More information about the grass-dev mailing list