[GRASSLIST:10785] Re: GRASS topographic position functionality beyond r.param.scale?

[Dylan Beaudette]

Greetings all,

I would be highly critcal of any algorithm that does not have all of
its "innards" available for the vewiing. In addition, the description
of the algorithm for representation of "valley" to "ridge" numerically
is a bit mysterious. The concept of "valleys" and "ridges" is not
easily captured by a single numerical index --- Indeed, I find the
referenced paper rather suspicous as they fail to mention exactly
_how_ they do a lot of things. This is not altogether surprising, as
GIS is often thought of as a magical black box that just does things--
meaning that those things do not need some explanation or
justification.

Conventionally, slope position as defined in most soil science
literature (summit, shoulder, backslope, foot slope, toe slope, etc.)
is often best estimated by the use of the different types of surface
curvature (plan, profile, tangential). Topographic indices such as the
TCI can also be helpful at empirically determining slope position-- if
field data is available for development of a model.

I would suggest r.param.scale, r.terraflow, and r.slope.aspect as a
starting point. An excellent paper which attempts to map out slope
position is:

[Park et al.(2001)Park, McSweeney, and Lowery]	S.J. Park, K.
McSweeney, and B. Lowery. Identification of the spatial distribution
of soils using a process-based terrain characterization. Geoderma,
103:249–272, 2001.


..Another trick might employ re-coding upslope contributing area for
each cell: cells with low values are most likely summits, while those
with the most are probably the valleys...

Cheers,

Dylan



On 3/5/06, Trevor Wiens <twiens at interbaun.com> wrote:
> On Sat, 4 Mar 2006 20:14:44 -0800
> Graham Watt-Gremm <sunyata at uvic.ca> wrote:
>
> > Hi Ian (and/or GRASS user list),
> > Did you ever get a response to this query, or develop something
> > yourself? I would like to get at the (unidentified Arc/Info) slope
> > position algorithm used by Wimberly and Spies (2001, Ecology 82(5):
> > 1443-1459), where topographic position grades from 0 at valley bottom
> > to 100 at ridge top. I am thinking along the lines of using some of
> > the output from r.flow (flowline segments in each cell a function of
> > transformed distance from valley bottom), though I have no experience
> > with this module. Does anyone have any suggestions?
> >
> > Cheers and thanks,
> >
> > Graham Watt-Gremm
> > Rocky Mountain Repeat Photography Project
> > School of Environmental Studies
> > University of Victoria
> > sunyata at uvic dot ca
> >
> > [GRASSLIST:1410] GRASS topographic position functionality beyond
> > r.param.scale?
> >
> > Ian Allan iallan at geocode.com.au
> > Mon, 06 Oct 2003 12:29:41 +1000
> >
> > Previous message: [GRASSLIST:1408] Finished
> > Next message: [GRASSLIST:1411] compiling GRASS with tcl8.4
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >
> >
> > Hi
> >
> > Can anyone suggest a technique for determining topographic position that
> > would provide more information than r.param.scale? In particular, I'm
> > interested in mapping upper slopes, mid slopes and lower slopes.
> >
> > Many thanks
> >
> > Ian Allan
> >
>
> Another option to consider is the topographic convergence index
> calculated by r.terraflow (if you have C++ support included).
>
> T
> --
> Trevor Wiens
> twiens at interbaun.com
>
> The significant problems that we face cannot be solved at the same
> level of thinking we were at when we created them.
> (Albert Einstein)
>
>