[GRASSLIST:7911] Re: Hutchinson's Adaptive Alogrithm for sound DEMs?

Brent Wood b.wood at niwa.co.nz
Mon Aug 15 16:39:26 EDT 2005


On Mon, 15 Aug 2005, Dylan Beaudette wrote:

> On Sunday 14 August 2005 09:42 pm, Brent Wood wrote:
> [snip]
> > (Even though lakes & rivers for breaklines do not really happen on the
> > seabed where I do most of my modelling :-)
> >
> > I'd like to make more use of GRASS for this, but have found it slow &
> > cumbersome to the point of being unuseable when compared with GMT for
> > generating DEM's from point data (say 20 million points).
>
> Brent how does the gridding procedure in GMT compare to v.surf.rst ? is speed
> being gained over loss in accuracy or flexibility?

Um. A few notes.

GMT supports blockmean/blockmedian/blockmode for pre-processing lists of
XYZ points to "fit" the grid before trying to grid the data. This can
dramatically reduce the number of points to grid.

For some of my work with commercial fishing catch/effort data, generating
a grid based on the sum of values per grid cell is useful, and can be done
with blockmean (a parameter prevents dividing sum by count in the output.
Very useful :-)


GMT uses "surface" (& a couple of other commands as well, but I find this
works for me. I may need to tweak the tension parameter depending on my
data, but around 0.7 usually seems close)

 see:
http://gmt.soest.hawaii.edu/gmt/doc/html/surface.html
http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node111.html#15221

Given the code is available, it may be feasible to port surface/blockmean
etc to GRASS? Need to ask a programmer :-)


FWIW I also got very robust & fast results using the minc (minimum-curvature)
command of the commercial GIS package Genamap. It was an implementation of
the algorithm described in:
Webring, M., 1981, MINC: A gridding program based on minimum curvature: U.
S. Geological Survey Open-File report 81-1224.

As I now only use OS tools, I don't have access to this any more :-)

>
> > If anyone has any ideas on how to address this & tweak performance I'd be
> > grateful, or if there is any specific info I can provide to help in this
> > area?
>
> there are some nice papers on tweaking the parameters for v.surf.rst and its
> kin in the recent GRASS 2002 conference proceedings [1].
>
> > A sort of "howto create a Spearfish-like DEM from raw point data" ??
>
> Again, one of Helena's papers talks about how to do this, and can be found on
> her website [2] (i have the relevant PDF if you would like it, but i
> originally found it here).

Yep. I have these, but still had problems with performance. One of the
issues was that generating a GRASS vector (point) dataset with all the
source data was slow & cumbersome, with the indices occupying much more
space than the data. I did get some suggestions from this list over that,
basically saying yes, that's it right now... so I stuck with GMT. I have
imported the GMT grids into GRASS to use with Nviz, with limited success,
the limits probably more due to the amount of time I spent than GRASS
itself.

(To be fair I must point out that I have basically dabbled in GRASS over
the years, rather than used it in earnest. My data is generally vector
based & GRASS has not always been an effective vector GIS. I do plan to
revisit GRASS/PostGIS/QGIS/R again.... But as GMT has worked well, with
GDAL/OGR etc, GRASS has not been a priority for me. Maybe when time
permits, sigh... :-)

>
> 1. http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/home.html
> 2. http://skagit.meas.ncsu.edu/~helena/gmslab/index.html
>


Thanks for the suggestions. DEM generation is an area of ongoing interest
& GRASS is _almost_ a useful tool for me in this. I'd love to see it
improved and become the DEM generating standard.


Thanks,

  Brent




More information about the grass-user mailing list