r.surf.contour runs for days

[Bob Harrington]

> 
> Dear Netters:
> There was a similar question sometime last week, however, I never saw it answer
> ed.
> Last Wednesday, I started r.surf.contour on a small area (2 x 3 km) with 10m re
> solution (background is a SPOT scene). After 48 hours the system tells me, that
> it is 10% done, a 'ps' command gave me something like 2600 minutes CPU time,
> that this process has used. Extrapolating this figure would give me 18 days! An
> answer to the above mentioned question asked for the parameters, that were used
>  But: r.surf.contour does *not* ask for any parameters (but filenames); as oppo
> sed to r.surf.idw, which ran for a few minutes only but with dissatisfying resu
> lts.

That was me that asked a similar question a week or two ago. I had been
trying to use r.surf.idw2 to make a DEM out of a rasterized contour map,
except I experienced the opposite problem as you -- I queried the list
after I had let r.surf.idw2 run overnight. It was suggested I use r.surf.contour,
which worked fine. This was on a fairly large map -- 700x900 or so.
I did use the -f option, which speeds up at the expense of memory.

> One hint could be the raster file used. I converted isolines with v.to.rast.
> Whereas the lines in the vector file were coninous, the "lines" in the raster
> file looked more like a dotted line. There were (although quite regularily)
> holes => the height values were not exactly neighboring each other. How this
> comes, I don't know. Again, the conversion routine doesn't ask for any paramete
> rs, so there doesn't seem to be much of a chance to do anything wrong.

My map has similar problems. It is of very mountainous terrain, and in
some places, the contours join or end when the come to a cliff. This caused
a few raggedy places in the raster map, but in general, r.surf.contour did
the trick. I don't really have any sure fire suggestions for you. Are the
isolines closely spaced in your map, or far apart? Maybe r.surf.contour
was pretty fast for me (a few minutes on a SPARC 10) because my contours
were close together, and the algorithm didn't have to look very far to find the
closest contours.

> By the way, does anybody know, how these routines are supposed to work? I mean
> the algorithm and/or assumptions (how many neighbors are taken into account, et
> c.) used.

When I asked about this, r.surf.contour was described as using a "flood fill
algorithm", what ever that is. The idw programs use inverse distance 
weighting, which is a distance weighted average of some number of nearest
points.

> Thanks for listening/reading
> 
>           Jochen
> 
> P.S.: Perhaps I should mention that the machine running that long is a Sparc2.
> 

Cheers,

Bob Harrington
Hydrology and Water Resources
University of Arizona
bobh at hwr.arizona.edu