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

[Glynn Clements]

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>