Philip Verhagen writes:
Matt,
(lines deleted)
3) Nevertheless, if you have only minor changes in your elevation
data you will always get steps. For example: if your elevation
changes from say 10 to 9 and the surroundings cells all have
values of 10 up-slope and 9 down-slope, there will always be a
contour-line like zone with an (unrealistic) slope-value that
will be equal to the ratio of 1 elevation-unit and the pixel-size
I have had this problem with elevation data from a flood-plain,
where elevation-steps are in meters; with a resolution
of 10x10 meters, you will get a slope-value of 10% (equal to a
elevation change of 10 meters in 100 meters) in an area which is
almost flat, or has slope of at most 0.5 to 1%. There's only one
solution to this, as GRASS doesn't support floating-point data:
multiply your original data with 100 or 1000 and do the interpolation
again. You'll have to find a way to get rid of the exaggeration when
you want a real slope-map afterwards, but I suppose r.mapcalc could do
the job.
Both r.slope.aspect and s.surf.tps (which can generate slope and aspect maps
directly) include "zfactor" arguments to use in cases like this. Thus, if you
multiply your data by 100 and run your interpolation program of choice, you can
still generate accurate slope and aspect maps. I'm glad that someone was awake
when they wrote these programs! Now, about that floating point...
--
Malcolm D. Williamson - Research Assistant E-mail: malcolm@cast.uark.edu
Center for Advanced Spatial Technologies Telephone: (501) 575-6159
Ozark Rm. 12 Fax: (501) 575-3846
University of Arkansas
Fayetteville, AR 72701