[GRASS-user] interesting article on TIN generation

Dylan Beaudette dylan.beaudette at gmail.com
Tue Sep 23 12:16:21 EDT 2008


On Tue, Sep 23, 2008 at 1:17 AM, Hamish <hamish_b at yahoo.com> wrote:
> 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.
>

Indeed-- the segmentation artifacts are a bit annoying, although I
cannot offer any alternatives other than increasing the segmax
parameter.

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

Haven't done that analysis yet, but it would be fun to try :) . I will
be at AGU with Helena this December, maybe we can get some ideas
together before then and I will present them to her at the conference.
I see that there are several ideas / problems / etc. posted on the
wiki:
http://grass.osgeo.org/wiki/RST_Spline_Surfaces


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

interesting...

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

Again, I tend to feel that same way-- unless you are working with some
kind of hardware-accelerated triangle rendering device (i.e. OpenGL
interface to video card) to *display* a surface in real-time, TINs
seem like overkill. However, the TIN data structure is appealing when
you want to store more information where there is more local
variation: i.e. rugged terrain gets more triangles/area than a valley
floor would get. Perhaps a well-designed, quadtree-indexed (or tiled?)
raster data model could function in a similar fashion...?


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

We really should get the nnbathy code / algorithm into a standard
GRASS module. For quick and dirty interpolation / large areas it is an
ideal approach.

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

+1 on this idea. Just need to look over the licensing / or find an
algorithm to stuff into a new module.

Cheers,
Dylan

PS: just back from the southern hemisphere (Rarotonga)


More information about the grass-user mailing list