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

[Doc Robinson]

>Date: Tue, 20 Jan 2009 21:22:41 -0700 From: Michael Barton <michael.barton at asu.edu> 
>Subject: Re: [GRASS-user] Aspect direction in r.slope.aspect 
 >To: grass-user at lists.osgeo.org
>Jan 20, 2009, at 8:38 PM, <grass-user-request at lists.osgeo.org> wrote:
>> > Date: Tue, 20 Jan 2009 14:05:41 -0800
>> > From: Dylan Beaudette <debeaudette at ucdavis.edu>
>> > Subject: Re: [GRASS-dev] Re: [GRASS-user] Aspect direction in
>> > 	r.slope.aspect
>> > To: grass-dev at lists.osgeo.org
>> > Cc: grass-user at lists.osgeo.org, Helena Mitasova
>> > 	<hmitaso at unity.ncsu.edu>
>> > Message-ID: <200901201405.41907.dylan.beaudette at 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 at unity.ncsu.edu it
>>>> >>> reaches grass-user directly.
>>>> >>>
>>>> >>> Markus
>>>> >>>
>>>> >>> On Tue, Jan 20, 2009 at 8:39 PM, Moskovitz, Bob
>>>> >>>
>>>> >>> <Bob.Moskovitz at 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
> 
> 

Here are my two cents on the topic as I have been using/teaching GRASS 
for more than a decade now.

1. I see no compelling reason to change r.slope.aspect. Actually I use 
it in my courses as a way to motivate students to read the manual and be 
aware of what their software is doing.
2. It is so simple to convert, it seems a waste of valuable time to 
change it. Having a simple flag for the option would be ok - users would 
still have to 'read the manual'. OR on the manual page just have simple 
example of how to convert it.
3. I have students write a simple script to that same thing. It is a 
useful exercise and quite a simple mind exercise.
4. What then about r.param.scale? Output is in the 0 +/- 180 range 
rather than 0-360. Will this also need changing? I have a similar 
comment on this. It is so simple to convert, when needed, why bother 
with a 'recode'?


-- 
Regards,
          Doc

  --------------------------------------------------------------------
    Vincent B. Robinson       |
   Department of Geography    | E-Mail: doc.robinson at utoronto.ca
    University of Toronto     | Voice: (905)828-5299
       at Mississauga         | Fax:   (905)828-5273
    Mississauga, Ontario      |
    Canada     L5L 1C6        |