I guess I misunderstood. If that is the case, then both Isaac and I agree 100%. The only thing is that, IIRC, there was talk awhile back about making MFD a flag. If so, we'll have to deal with that in the script. Maybe we can use g.version to ID grass 6.4 and add the flag.
Michael ____________________ 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 5:51 PM, Helena Mitasova wrote: > I think what Markus M was trying to say is that there is a need to release > GRASS64 > with the new r.watershed (currently available only in GRASS65) that is far > superior than r.watershed that is in the release. > We tested the new r.watershed quite a bit here and so far haven't found any > problem, > which of-course does not guarantee that it is completely bug-free, but I > would like to hear from others > (Glynn, Hamish, Scott, Markus N. and others) whether it would be sensible to > release > GRASS64 with the new r.watershed. It would certainly make my life easier. > > Helena > > On Apr 28, 2010, at 4:48 PM, Michael Barton wrote: > >> 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 >>> <[email protected]> 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 >>>> *************************************************** >>>> [email protected] >>>> [email protected] >>>> >>>> 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 >>> *************************************************** >>> [email protected] >>> [email protected] >>> >>> http://www.public.asu.edu/~iullah >>> *************************************************** >> > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
