Date: Tue, 20 Jan 2009 21:22:41 -0700 From: Michael Barton <michael.barton@asu.edu> Subject: Re: [GRASS-user] Aspect direction in r.slope.aspect
>To: grass-user@lists.osgeo.org
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,
>
> DylanFor 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@utoronto.ca
University of Toronto | Voice: (905)828-5299
at Mississauga | Fax: (905)828-5273
Mississauga, Ontario |
Canada L5L 1C6 |