r.surf.contour

[John Mackenzie]

Hi Yung-Tsung Kang,

Here are some observations on r.surf.contour from someone with a lot
less GRASS experience than you have:

The program works best when the region is set tight around the raster
lines, with little or no edge of zeroes.  Running time increases 
dramatically as you reduce resolution, so maybe try a 500-meter run
first.  My Sparc IPX can take 40 minutes or more to do a 30-meter DEM 
for a 7.5-minute quad, depending on the sparseness of the hypso data;
that's a lot smaller problem than you're attempting.

In creating DEMs from rasterized DLG hypso data in coastal 
areas, I have extracted shorelines from hydrography as 1's, and added 1's 
everywhere there's water or a hypso line, so the only zeroes are land
areas.  This prevents the program from wasting time in corners
with zeroes.

I wouldn't be surprised that ArcInfo can do such interpolations faster.
It takes some pretty zippy numeric integration routines to work with
its vector data structures.  

Since your application is a little non-standard, check out GRASS's
other interpolation modules (both 2D and 3D) available in the 
incoming directory on the moon server.  Splining and
tensioning and other nice stuff.  We've tried 'em some and like 'em lots. 

Happy Holidays!
John Mackenzie
U. of Delaware

> Has anyone ever tried to run r.surf.contour?  I have a groundwater table
> contour map for the lower peninsula of Michigan.  I use it as the input to the
> r.surf.contour to generate a continuous surface for groundwater table.
> However, the process is so slow, 0 percent done after more than 900 minutes,
> I had to kill it eventually.  I am running on a SUN SPARC 20.  Although my
> resolution is about 100 meters for a region of 4550 x 3650 cells, I really 
> didn't expect it to run so slow.  This brings up three issues for comments and
> suggestions.
> 
> First, why the process is so slow on GRASS?  I have a lot of proof that the 
> ARC/INFO GRID always runs faster than GRASS on the similar functions, especially
> those functions required computational power and those maps having a large 
> number of cells.  Is this the result of program inefficiency or the result of
> the data strucutre.

> Yung-Tsung Kang,
> Center for Remote Sensing, Michigan State University