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 <[email protected]>
Great ideas!
Michael
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
