[GRASS5] r.slope.aspect in feet

Glynn Clements glynn.clements at virgin.net
Thu Jan 29 05:51:59 EST 2004

Helena wrote:

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

Probably neither.

GRASS knows what the X/Y units are from the PROJ_UNITS file. It
doesn't know what the Z units are, so it either has to be told or it
has to make an assumption.

I'm not sure that assuming that the Z units match the X/Y units is an
improvement over consistently assuming that the Z units are metres. 

There is also the fact that, as the historical behaviour is to assume
metres, changing it to assume either feet or metres depending upon
PROJ_UNITS would break compatibility. Worse, it could result in
existing scripts suddenly giving wrong answers.

The least problematic fix would be to change:

    parm.zfactor->required    = NO;
    parm.zfactor->required    = YES;

That would force the user to specify the units, eliminating the need
for any assumptions. Existing scripts would fail, but would do so

Glynn Clements <glynn.clements at virgin.net>

More information about the grass-dev mailing list