The reality is that this kind of modeling works well and is accurate for the new MFD routine in r.watershed but does not work nearly as well with r.terraflow or with SFD in r.watershed.
Helena originally proposed this for r.flow, which is how we started out several years ago. However, as we developed this modeling script, we learned that a full hydrology model worked better than the flow lines information generated by r.flow. So we switched to r.terraflow. However, the routines of r.terraflow produced numerous 'artifacts' in the way of anomalous spikes and pits that could self-amplify over multiple iterations. We used smoothing routines to get rid of these. This worked OK, but affected both accuracy of estimating erosion/deposition and the speed of calculation (median smoothers take awhile to run). We have a paper coming out that uses this version of r.landscape.evol (the previous version that is still in addons and downloadable). The old version does what it can to work around the limitations of the watershed routines that are now standard in GRASS 6.4 Running with the new r.watershed and MFD, however, does not create the kind of artifacts we saw with r.terraflow and does not require post facto smoothing. This makes it much faster and more accurate in its erosion/deposition estimates. Also, the smoothing never was able to completely eliminate the terraflow artifacts, but these simply don't exist with r.watershed and MFD. I guess I don't see the point of dumbing down the new version of the script to work with GRASS ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Apr 28, 2010, at 12:02 PM, Isaac Ullah wrote: > I suppose that is true from a programmatic point of view, but from > scientific point of view, the fact is that MFD makes the module so much more > useful that it's pointless to run it with r.terraflow (or SFD r.watershed). > Actually, I imagine that including the flag to run r.landscape.evol.py with > SFD terraflo/r.watershed is actually being disingenuous, as I'm not even sure > that the stream erosion equation can even make valid output using SFD (I need > to test this, but my feeling is that it will produce overly-large estimates). > > I guess that means, then, that I am advocating for backporting of 6.5 > version of r.watershed to 6.4. Why put out the next stable version of GRASS > with clearly inferior capabilities? This IMO is simple guaranteeing the quick > obsolescence of the stable GRASS version for anyone actually interested in > doing state-of-the-art, cutting-edge, robust research with it. It would make > much more sense to me (as a scientist who uses GIS as a tool) to include the > best available version of modules in a new release. I understand that one > does not want to "break" any dependencies (and thus one should generally try > to avoid changing the number/arrangement of module inputs), but surely this > can be done for situations where the benefits so greatly outweigh these > costs? I imagine that only myself and perhaps a few other scripters will have > dependencies on r.watershed, and we can easily amend our scripts to be > compatible... > > Cheers, > > Isaac > > On Wed, Apr 28, 2010 at 11:30 AM, Markus Metz > <markus.metz.gisw...@googlemail.com> wrote: > Isaac Ullah wrote: > > Yes, this is certainly true. We have kept backwards compatibility with a > > flag to use r.terraflow if the user has GRASS 6.4 or less. > > GRASS 6.4 is the next stable release for some time to come, thus new > addons for GRASS 6.x should IMHO be tailored for 6.4. Either you > advocate the backporting of the 6.5 version of r.watershed to 6.4 ;-) > or you make r.terraflow the default, with a flag indicating to use > r.watershed. > > Anyway, IMHO, newly updated addons should run in 6.4 with the default > settings. > > Markus M > > > > Markus Metz wrote: > >> > >> Isaac Ullah wrote: > >> > > >> > > >> > [The new "r.landscape.evol.py"] takes advantage of the advanced MFD flow > >> > routing capabilities of the newly > >> > updated r.watershed module, which produced more accurate stream > >> > networks, > >> > and flow accumulation values. > >> > >> Nice, but "r.landscape.evol.py" works only with the GRASS 6.5 version > >> of r.watershed, otherwise > >> r.terraflow must be used. Contrary to the 6.5 version, the 6.4 version > >> of r.watershed only supports SFD (D8) and only integer DEMs, floating > >> point DEMs are truncated to integer(, and it's slower and uses more > >> memory). > >> > >> Markus M > > > > > > > > -- > > Isaac I Ullah, M.A. > > > > Archaeology PhD Candidate, > > ASU School of Evolution and Social Change > > > > Research Assistant, > > Mediterranean Landscape Dynamics Project > > *************************************************** > > isaac.ul...@asu.edu > > ul...@archaeologist.com > > > > http://www.public.asu.edu/~iullah > > *************************************************** > > > > > > -- > Isaac I Ullah, M.A. > > Archaeology PhD Candidate, > ASU School of Evolution and Social Change > > Research Assistant, > Mediterranean Landscape Dynamics Project > *************************************************** > isaac.ul...@asu.edu > ul...@archaeologist.com > > http://www.public.asu.edu/~iullah > ***************************************************
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
