[GRASS5] TINs as 3D vectors

[Pieter Bos]

----Original Message-----
From: Radim Blazek [mailto:blazek at itc.it]
Sent: Tuesday, April 19, 2005 12:34 PM
To: Pieter Bos
Cc: GRASS Developers list
Subject: Re: [GRASS5] TINs as 3D vectors

Pieter Bos wrote:
> Hmm, indeed, it does not, which means it can't be distributed with 
> GRASS. But should be ok to just use/distribute it as a add-on module 
> separately, as this is a separate program (right?). Not an ideal 
> solution indeed. Would have to email the author to find out. We're 
> using it for research purposes, which is allowed.

Hopefully you convince him to release Triangle under some decent
license. TIN is  general task which should be included in standard GRASS
package.

I agree, I'll see what I can do.

> Conversion from Raster to TIN is not directly done, however, Triangle 
> handles a square grid of points just fine. I haven't tried r.to.vect, 
> but it looks like it can convert raster data to a vectormap with a 
> point for every pixel in the map, which is what is needed as input. It

> is possible to simplify the surface a bit by removing adjacent 
> triangles in the same plane and replacing them by fewer triangles.
> This is currently being finished.

It would be nice to have it in one module (r.to.tin) to avoid large
vector before simplification, it is simple to read points from raster.

I agree, might even be a good addition to what we're doing, I'll see
what I can do. However, the simplification currently is done in the
alpha-shape, requiring a full retriangulation but now with constraints -
we need the alpha-shape anyway everytime ourselves and need the
possibility to add more constraints if needed anyway as well, so the
simplification is included there as a constraint. So you would need the
large vector data anyway, although it could be deleted afterwards.

I hope this is understandable, our process of input would be:

1. Do a delaunay triangulation
2. Perform the alpha-shape algorithm, delivering the boundaries of
objects, the points inside them and extra constraints for the
simplification.
3. Do a constrained delaunay triangulation.

Without simplification and extra constraints, step 3. can be skipped and
2. can output a triangulation directly. This approach is chosen because
in the future it might be needed to add extra constraints after step 2,
which is now possible by just adding lines with type line for line
constraints, or with type boundary to define objects. The output of the
alpha-shape for example could be something like this, all lines type
boundary:

---------------|
|   area 1     |
|  --------    |
|  | area 2|   |
|  |       |   |
|  --------    |
|              |
---------------

When run through the triangulation again area 1 will contain triangles,
area 2 will be a hole without any triangles. If there's any area inside
area 3, triangles are created in it again.

So we do create large vectormaps, unfortunately.

> with any license here. However, you would need some module to create a

> delaunay triangulation, v.delaunay works fine for small datasets...

Sounds good, do you have anything which can generate contours from TIN?

What do you mean exactly with contours? The outer boundary of the TIN is
very easy to generate, just output all boundaries of a TIN that only
have one triangle adjacent to them, instead of two. We have something
that can add a different category value to different 'objects' (objects
consist of connected triangles) automatically as well. 

We also have used the GNU triangulated surface
library(http://gts.sourceforge.net/, yes that does have a compatible
license) to calculate intersection lines between two TIN's, which are
lines where the TIN's have the same x,y and z-value. (we compute the
union, intersection and difference of vague objects with them - although
those are defined for vague objects and might probably not be of general
use). You could probably modify it to calculate contour lines with that
as well by intersecting with some horizontal surfaces, if you would want
to, although I'm sure a better approach is possible.

There is 2D visualization though, which currently maps z values between
0.0 and 1.0 to a gray value. Can be changed to accept any range of
z-values, if needed. Supports showing several TIN's(vectormaps..) at
once, using transparency and different colors to distinguish the
different TIN's. However, you'd need a new front-end to call this
visualization, it now works by reading the names of several vectormaps
stored in a database and only works with the limited z-value range. Not
much work to do, if required... Would be of any use?

So, say what is useful and most of it can be released, probably. It
would require some work, because some things specific to our purpose
would have to be removed or changed. We're finishing our own things
first. After that I'll have time to release this properly for general
purpose TIN support and promise I will (or perhaps Pawalai, who was also
working on this and reads this, will before I do? ;)). Might be before
end of next week, otherwise I can do it in about a month, going on a
trip first.

Pieter

PS. Sorry for omitting the > in front of the old e-mail, don't know how
to configure this e-mail client to act differently