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

GRASS GRASS user
1

On Jan 20, 2009, at 8:38 PM, <grass-user-request@lists.osgeo.org> wrote:

Date: Tue, 20 Jan 2009 14:05:41 -0800
From: Dylan Beaudette <debeaudette@ucdavis.edu>
Subject: Re: [GRASS-dev] Re: [GRASS-user] Aspect direction in
  r.slope.aspect
To: grass-dev@lists.osgeo.org
Cc: grass-user@lists.osgeo.org, Helena Mitasova
  <hmitaso@unity.ncsu.edu>
Message-ID: <200901201405.41907.dylan.beaudette@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Tuesday 20 January 2009, Helena Mitasova wrote:

On Jan 20, 2009, at 3:16 PM, Markus Neteler wrote:

Helena,

I guess this is a question for you. If you post from
hmitaso@unity.ncsu.edu it
reaches grass-user directly.

Markus

On Tue, Jan 20, 2009 at 8:39 PM, Moskovitz, Bob

<Bob.Moskovitz@conservation.ca.gov> wrote:

Hello Grass Users,

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.

at the time when it was implemented there was no other major raster
GIS (no Spatial Analyst, only
some research software and each used different rule, based on the
background
of the developer), so it was done to conform how the angles are
measured in math (east is your +x
and the values increase counterclockw).
I vaguely remember discussions on whether to change it to conform with
the "aspect as azimuth" concept with 0 pointing towards North but
there were already too many
people used to the way it was originally implemented that it was
safer to keep it.
(we had to make the decision for aspect in v.surf.rst as well and we
decided
to keep the math convention to make it consistent with r.slope.aspect).

GRASS7 provides opportunity to change it and make sure that all
modules that compute and use
aspect or flow direction conform to the same rule. But it would be a
major undertaking that could
break a lot of scripts - I am not sure it is worth it and whether
anybody would actually be
willing to do it - it really depends on what your background is.
So if there are people who think this is really important and there
is some official standard that
says what it should be and there are some volunteers to actually work
on it, please post
to the grass-dev list,

Helena

Good topic for discussion. I think that GRASS7 should stick with the current
conventions to retain backwards compatibility. Since the reference of the
aspect calculation is clearly spelled out in the manual there should be no
problem- as long as people read the manual. Perhaps a careful check of all of
the manual pages associated with directional calculation should be checked to
make sure that there is a note.

Cheers,

Dylan

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).

It is important to get an idea of how many things actually would need to be changed.

Michael

2

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@gclements.plus.com>

3

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@gclements.plus.com>

Great ideas!

Michael

4

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

5

Sounds like a great idea! If sometrhing like this can be done, we would have one less reason to shy away from FOSS.

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).

It is important to get an idea of how many things actually
would need
to be changed.

Michael

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

6

Good topic for discussion. I think that GRASS7 should stick with the
current conventions to retain backwards compatibility.
Dylan

But I thought the whole idea of GRASS7 was to introduce new functionality
that is not necessarily intended to be backwards compatible with 6.x series?
The place to make the change, if anywhere, must certainly be in 7 as so much
else is changing in the codebase as well.

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 agree. Measuring counter-clockwise from east is completely counterintuitive
from my point of view. Why make it more complex than it needs to be?

~ Eric.

7

I agree. Measuring counter-clockwise from east is completely counterintuitive
from my point of view. Why make it more complex than it needs to be?

Sorry, just catching up to the discussion; I hadn't read some points in the thread
further along; just because it seems more complex to me doesn't necessarily make it so :wink:

~ Eric.

8

On Thu, Jan 22, 2009 at 3:05 PM, Patton, Eric
<Eric.Patton@nrcan-rncan.gc.ca> wrote:

Good topic for discussion. I think that GRASS7 should stick with the
current conventions to retain backwards compatibility.
Dylan

But I thought the whole idea of GRASS7 was to introduce new functionality
that is not necessarily intended to be backwards compatible with 6.x series?
The place to make the change, if anywhere, must certainly be in 7 as so much
else is changing in the codebase as well.

I agree. GRASS 7 is there to make radical changes.

In this particular case we could add metadata, if not present it
is apparently GRASS 6 data stuff, otherwise read what the
metadata suggest for the orientation.

Markus