continuous thermal data and r.slope.aspect

Alastair Duncan 100074.213 at compuserve.com
Wed Aug 7 08:00:00 EDT 1996



Philip Verhagen wrote :

>> Does anybody know what these values would mean in terms of temperature chang
e
>> per metre ? The resolution is 8 metres, and setting the zfactor to 1 means
 that
>> 1/16th of a degree Celsius is being treated as 1 metre in the r.slope.aspect
>> program.
>
>Alastair,
>
>percent slope is equal to 100 * (vertical change / horizontal change).
>The vertical units are irrelevant, so this can also be used for other gradient
s
>than elevations. Your temperature map should be multiplied by 0.0625 to
>to get a map in degrees, so if I read the manual right, this should be
>the z-factor you have to use. Note that the output from r.slope.aspect
>give cell values that are equal to percent_slope + 1.
>
>Good luck,
>
>Philip Verhagen

Thanks for getting back to me regarding my query - it helped straighten out in
my mind with regard to what I'm trying to represent and led to the following
thoughts:

        When describing whether a point on a continuous surface (other than
terrestrial elevation) is in a position of relative high or low change in the Z
value by distance, rather than using the traditional slope values to describe
change, wouldn't the averaged absolute differences in Z value by distance
between a central pixel and all eight neighbouring pixels in a 3 by 3 filter (o
r
all 24 pixels in a 5 by 5 filter) give a conceptually more meaningful measure o
f
relative change over a surface? The slope value is obviously great for digital
terrain modelling, geomorphology, hydrology, etc. but for continuous surfaces
such as thermal data, population density, chlorophyll fluorescence, ozone
levels, etc, etc what is the use knowing change in Z value by distance in just
one direction - the direction of maximum negative difference at that, compared
to the average change in Z value in all directions around the point ? - a much
more balanced index of change (with less potential to being influenced by
spurious values in the continuous surface raster being analysed - especially if
you take a weighted average of the differences in a 5 by 5 filter).  

I've tried out this idea using r.mapcalc and it seems to work very well with my
thermal data - giving a raster layer where the value of each pixel represents
average difference in temperature by distance, ie degree C/km change. Before I
code up the algorithm into a script or GRASS program, has anybody else done thi
s
before or know of any other work that has done this (no point in re-inventing
the wheel). Would anybody else find this useful or have any critisisms of the
technique??

Cheers, Al.


Alastair Duncan,
GIS Data Officer,
The National Centre for Environmental Monitoring and Surveillance,
The Environment Agency,
Bath, UK






More information about the grass-user mailing list