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

[Michael Barton]

On 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