On Tue, Sep 23, 2008 at 1:17 AM, Hamish <[EMAIL PROTECTED]> 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) _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
