[GRASS-user] interesting article on TIN generation

[Hamish]

Vincent Bain wrote:
> As I spend a couple of days computing a huge lidar dataset
> (first split the original file in 145 pieces ! then performing a
> loop with v.surf.rst, and rearrange data in a single raster), it is
> of great interest for us.

I still look for a nice method to paste together overlapping splines
cleanly.


<rant>
IM(V)HO, the surface created by v.surf.rst splines will be an order of
magnitude(s) closer to reality and is really worth the extra effort.
I haven't run any analysis to back that up quantitatively, perhaps Dylan
already has? ;) (well maybe not, but I wouldn't be surprised)
</rant>

<boring anecdote>
In years long past I did some 3D density modelling in which case I could
for a test case solve the answer analytically to test my iterative
solution. After the iterative solution had been running for a while I
added some instrumentation to see what cell resolution and time it
would take to get within the required % of the known answer using the
linear interpolation method. It turned out that my process would finish
in about 126 years using the Sun workstation of the day. I canceled
the job and rewrote it using 3D trapezoids instead of Q-bert blocks.
It finished in 5 minutes. Ok, for that the solution /was/ a form of
TIN, but I think the idea scales between linear and cubic interpolations.
</boring anecdote>

<back to rant>
IM(V)HO the fact that TINs are used so much to make raster surfaces is
an artifact kludge from a history of other well known GIS which was
historically strong with vector data but weak with raster data (ie
the opposite to GRASS's history). IM(V)H estimation, among the many
hundreds of GRASS modules and 25 years, TINs conspicuously never made
an appearance in GRASS for the simple reason that there was no need
for such a poor solution when much better ones were already available.

In the face of a strong raster engine things like TINs are perhaps
handled more efficiently and directly dealt with by the display drivers.
</rant>

If speed is a real limiting factor I'd suggest trying v.surf.idw(2),
or perhaps r.surf.nnbathy*. Maybe they hit the time vs. results
tradeoff sweet spot better.


> Perhaps could this code be turned into grass module ? well,
> it's beyond my skills, but...

I could have sworn there was a TIN module on the wiki addons page, but
don't see it now.

Maybe it was lurking in the R-interface tutorials or somewhere?
(The grass wiki as-setup doesn't search for 3 letter words, which is
a bit of a problem)


3c,
Hamish


[*] Is there any thoughts on moving r.surf.nnbathy into the main source?
It requires an external dependency to use, but so do many other scripts.
To me it's a valuable addition to the available quiver of interpolation
methods; a nice compromise between IDW and splines. Before doing that I
think to change it to be v.surf.nnbathy (its first step is r.to.vect).