r.slope.aspect problems

[Malcolm Williamson]

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 at 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