[GRASS5] r.slope.aspect in feet

Helena hmitaso at unity.ncsu.edu
Wed Jan 28 20:51:11 EST 2004


Before GRASS5.3 is released I would like to point out that
if the data are in a coordinate system that uses feet
r.slope.aspect quietly converts x,y to meters while leaving z in feet
leading to greatly exagerrated slopes.
I looked into the code and it seems that
G_begin_distance_calculations(), G_distance,
automatically converts to meters.

Is this a desired behavior? If yes, r.slope.aspect should return a warning
as there is no way for the user to know that r.slope.aspect is converting
x,y to meters which means it is the users responsibility
to convert z to meters using zfactor, which is slightly indicated in help
and in manual but it is not really clear. Should this be fixed by

-adding the warning (and a sentence in manual that elevation MUST
be converted to meters by zfactor, now it sounds as if zfactor was there
for the case when x,y is in meters and z is in feet)

or

-skipping the conversion (that may be complicated)

Are there any other modules that could be negatively affected by this conversion?
For example, d.measure returns distances in meters, but it says "meters", so there is no
  confusion, although the manual says "Line lengths are stated in the same units as
those of the current LOCATION", so for those who read the manual there is confusion.
On the other hand r.profile clearly states that it outputs the profile length
in meters (I assume that it uses G_begin_distance_calculations() too).
Moreover, if there are programs that output the distance without writing the unit,
  e.g. piping it to another program, the automatic conversion may cause problems.

I really wish that feet and similar obscure units would go away but it seems that
we will have to deal with them for a while as the newest LIDAR-based DEMs and flood
maps in my state are all published in feet.

thank you for any help with this,

Helena




More information about the grass-dev mailing list