[GRASS5] r.slope.aspect in feet

[Glynn Clements]

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;
to:
    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
visibly.

-- 
Glynn Clements <glynn.clements at virgin.net>