[GRASS-user] Aspect direction in r.slope.aspect

Michael Barton michael.barton at asu.edu
Wed Jan 21 09:40:46 EST 2009


On Jan 21, 2009, at 7:26 AM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>>>>>> I was just wondering why aspect is measured from the east and  
>>>>>> increased
>>>>>> counterclockwise instead of the north and clockwise?  It seems  
>>>>>> to run
>>>>>> counter to what is done in other GISs.
>
>> For my 2 cents worth, it seems to make a lot more sense for a
>> *geographic* information system for all output to follow the same
>> spatial organizational standards. I understand the history of the  
>> east
>> is 0 convention for parts of GRASS. And I also appreciate the
>> importance of not breaking code-dependent features within versions.
>> However, that does not mean that we should keep a non-standard way of
>> measuring direction for select modules (like r.slope.aspect), while
>> measuring from north for others, simply because the program started
>> out that way. Version changes are a time when we can rethink and
>> standardize different modules that have evolved independently.  
>> Scripts
>> are likely to break across the 6/7 transition for other reasons  
>> anyway.
>>
>> That said, a functionally simple approach that would not be quite so
>> disruptive would be to add a flag to switch to count from east mode
>> (with count from north as the default) or even a flag to switch to
>> count from north mode (with count from east being the default if
>> backward compatibility is indeed very important in this case).
>
> I would suggest generalising it to scale and offset, so that you can
> use degrees, grad, radians, etc. E.g.:
>
> 	scale	offset	description
> 	360	0	degrees CCW from east
> 	-360	90	degrees CW from north
> 	2*pi	0	radians CCW from east
> 	-400	100	grad CW from north
>
> We also need a flag to indicate whether angles are signed or unsigned,
> e.g. 0..360 vs -180..180. Off the top of my head:
>
> 	struct angles {
> 		double scale, offset;
> 		int is_signed;
> 	};
>
> 	double G_import_angle(const struct angles *f, double a)
> 	{
> 		return (a - f->offset) * (2*M_PI) / f->scale;
> 	}
>
> 	double G_export_angle(const struct angles *f, double a)
> 	{
> 		a = f->offset + a * f->scale / (2*M_PI);
> 		return a - f->scale * floor(a / f->scale + f->is_signed ? 0.5 : 0);
> 	}
>
> We would also want a function to set the conversion parameters from a
> string, so that common cases can be named (e.g. "deg,geo" for
> degrees/CW/north, "rad,math" for radians CW from east).
>
> Then, modules such as r.slope.aspect would get an angles= parameter,
> with the existing interpretation as the default.
>
> -- 
> Glynn Clements <glynn at gclements.plus.com>

Great ideas!

Michael



More information about the grass-user mailing list