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

[Hamish]

Dylan:
> Good topic for discussion. I think that GRASS7 should stick with the
> current conventions 

I agree,  (in spite of my mapping background being from the navigation
end of things)


> to retain backwards compatibility.

most importantly-> backwards compatibility with existing maps, this is
not just about updating scripts.


Dylan:
> 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.

by the way, what is a good name for the "CCW from +x" style? currently
we call it "grass" but surely there is a more self-explanatory name for
it.

related: "v.in.ascii format=standard" (yet not the default) is not clear.


Michael:
> However, that does not mean that we should keep a non-standard way of
> measuring direction

CCW from +x is in no way non-standard. It is just a different (equally
valid*) standard.   *(depending on your background/POV)

> for select modules (like r.slope.aspect), while measuring from north
> for others,

currently AFAIK there is:
r.slope.aspect, v.surf.rst:   degrees CCW from east

r.param.scale:    0 is west, +/-180 is east, +90 north, -90 south
		"Direction of maximum gradient (steepest slope
		 direction=flow direction)"

Nothing AFAIK currently outputs aspect as CW from north, although
d.rast.arrow accepts type=grass,compass,agnps,answers. (AGNPS is
multiples of 15 deg, and ANSWERS is D8)  I'm not sure if modules for working with the AGNPS & ANSWERS models are still active in GRASS6.

see also the aspect color rules.


> Scripts are likely to break across the 6/7 transition for other reasons
> anyway.

again, more important than scripts is existing data. New data should have
meta-data added to it specifying which conventions it uses. Old data
doesn't have that and it is hard to guess which it was, so the analysis
subtly gives you bad results without warning. +evil.

At minimum I think we should add a short "(degrees CCW from east)" note
to all option->descriptions which create aspect maps and ensure that
text is written in the raster output units/title/hist metadata structures
upon creation.

r.slope.aspect's r.info title and cats/ file (d.what.rast) goes to
great lengths to explain what the cell is.  r.param.scale does not.


> [...] add a flag to switch to count from east mode [...] or even a flag
> to switch to count from north mode

IMO that is a classic recipe for confusion and mayhem. It violates the
philosophy of creating strict output but reading sloppy input. It is
better to settle on a single way, document it well, and provide an
example of how to convert to something else if the user prefers.


Doc Robinson:
> 4. What then about r.param.scale? Output is in the 0 +/- 180 range
> rather than 0-360.

A similar issue there is meteorological vs. nautical conventions for flow
direction: southerly wind flows towards the north, southerly water flow
flow towards the south.  How do the groundwater flow people call it?
Also there is the convention that "north facing" is geo-centric.
Add to this radians vs degrees and true north vs magnetic and the result
is that you just have to be sure to document things really well so someone
from a different background doesn't make the wrong assumptions.

I suppose in a non-legacy world you could say that degrees are always
CW from north, and radians are always CCW from the +x axis, and not worry
about grads. but oh well.


Bob:
> Everything look great, but when we took another look at the various
> layers, we were shocked to see how aspect was defined.  I know...we
> should have read the manuals, but everybody knows how aspect is defined.

... for some values of "everybody". The way you expect to see it is
simply based on your background.


> it would be great if there was a document that shows the differences
> between GIS systems (such as ESRI, MapInfo, etc), so that we can keep
> surprises at a minimum. :-)

please help improve:
  http://grass.osgeo.org/wiki/GRASS_Help#Migration_from_other_GIS_Software



I am not fundamentally opposed to changing the default GRASS way to be CW
from north in GRASS 7 if there is strong consensus to change it, but I am
rather opposed to offering multiple ways.


best,
Hamish