Re: [GRASS-user] interesting article on TIN generation
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. > > 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) > 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 > > 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. > interesting... > > 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. > 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 grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
On Mon, Sep 22, 2008 at 11:10 PM, Vincent Bain <[EMAIL PROTECTED]> wrote: > Dylan, > 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. > Perhaps could this code be turned into grass module ? well, it's beyond > my skills, but... I have not looked over the license, but it would probably be beyond what my time/skill level permits. Have you considered using r.in.xyz (pre-filtering module) for your massive lidar dataset? Also, by submitting that article to the list, I wasn't advocating the use of TINs over grids-- I just thought it was interesting. I still think that for most modeling operations, gridded data are the simplest to use / understand. Cheers, Dylan > Le lundi 22 septembre 2008 à 15:53 -0700, Dylan Beaudette a écrit : >> Thought this would be of interest: >> >> http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf >> >> Cheers, >> >> Dylan >> > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Sorry I forgot the PS > [*] 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). Yes indeed it would be faster when starting from a set of vector points. > > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Le mardi 23 septembre 2008 à 01:17 -0700, Hamish a écrit : > I still look for a nice method to paste together overlapping splines > cleanly. Maybe first generating /sufficiently/ overlapping tiles, then adjust adjacent ones in the middle of the overlap (ok, not very clean) > 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 Yes, it's hard to ged rid of some old /educational/ reflexes. I agree ! but anyway, TINGRID was very useful. > If speed is a real limiting factor I'd suggest trying v.surf.idw(2), > or perhaps r.surf.nnbathy*. Very useful module if one needs to generate a non-interpolated surface, fitting exactly a given set of points. Could it become a default command in Grass ? > > > > 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) Maybe you confuse with the TIN how-to ? using Paraview and Meshlab http://grass.osgeo.org/wiki/HOWTO_create_3D_TIN > > > 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). > > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
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. 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) 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. 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. 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). ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interesting article on TIN generation
Dylan, 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. Perhaps could this code be turned into grass module ? well, it's beyond my skills, but... Le lundi 22 septembre 2008 à 15:53 -0700, Dylan Beaudette a écrit : > Thought this would be of interest: > > http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf > > Cheers, > > Dylan > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] interesting article on TIN generation
Thought this would be of interest: http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
