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@hwr.arizona.edu