On Wednesday 21 January 2009, 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.
If it wouldn't be too hard to implement, this seems like a nice generalized
solution. I had forgotten about the output from r.param.scale...
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
