[GRASS-dev] New version of the r.landscape.evol.py Landscape Evolution module uploaded to the GRASS Addons repository.

GRASS GRASS developer
1

Dear GRASS users/developers,

I’m happy to announce that the Mediterranean Landscapes Dynamics Project has released a brand new version of our landscape evolution script “r.landscape.evol.py”. It can be downloaded from the GRASS ADDONS SVN Repository in the LandDyn directory (http://trac.osgeo.org/grass/browser/grass-addons/LandDyn).

“r.landscape.evol.py” calculates erosion and deposition values for a region (DEM) given climactic (rainfall) and environmental (vegetation and soils) conditions. It can iteratively calculate these values over multiple time-steps, and will produce new surface DEM’s for each time step (using the previous DEM as input in the next time step). “r.landscape.evol.py” uses process-based transport equations to calculate erosion/deposition differently for different parts of the landscape (ie. flat areas, hillslopes, mass movement, small channels, streams).

The latest release fixes several small programing issues, and implements a new algorithm for calculating erosion/deposition in stream channels. It 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. “r.landscape.evol.py” uses process equations that capitalize on the strengths of the MFD algorithm. Additionally, “r.landscape.evol.py” has been completely rewritten in Python, with improved speed and in keeping with the direction of GRASS programing. We have also uploaded a very detailed help file, which explains the program, the equations, and their variables in great detail.

We encourage everyone to download and use the module, but if you do so, we request that 1) please let us know how it works, and provide us with any errors or anomalies you may discover, and 2) that if you publish research that uses “r.landscape.evol.py”, you credit the Mediterranean Landscape Dynamics (MEDLAND) Project of Arizona Sate University, and developers Isaac I. Ullah, C. Michael Barton, and Helena Mitasova, and mention that the module development was funded by NSF Grant BCS-0410269.

Please also note that there are many other scripts in the LandDyn addons directory. These are related to the Mediterranean Landscape Dynamics Projects modeling laboratory, where we are simulating early agropastoral landuse (farming and herding), and tracking their effects on landscapes (erosion/deposition rates and vegetation) through time. You may also find these other scripts of use, and we encourage you to try them as well (with the same requests for error reports and credits is used in publications). Most of these scripts are quite stable, but have not yet been documented to the extent that r.landscape.evol.py has been (ie., I have yet to write html manual pages for them). However, I have done my best to internally document them by creating abundant comments in the source code.

Cheers,

Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project

isaac.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

2

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

3

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 :wink:
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.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah
***************************************************

4

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.giswork@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 :wink:
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.ullah@asu.edu
ullah@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.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

5

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 <markus.metz.giswork@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 :wink:
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.ullah@asu.edu
> ullah@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.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah
***************************************************

6

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 <markus.metz.giswork@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 :wink:
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.ullah@asu.edu
ullah@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.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah
***************************************************

7

Michael wrot

Maybe we can use g.version to ID grass 6.4 and add the flag.

see also $GRASS_VERSION enviro variable

Hamish

8

Great. Thanks.

Of course it's moot if r.watershed in 6.4 stays the way it is with no MFD.

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 9:37 PM, Hamish wrote:

Michael wrot

Maybe we can use g.version to ID grass 6.4 and add the flag.

see also $GRASS_VERSION enviro variable

Hamish

9

Helena 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.

AFAIU the plan was to backport it from 6.5 soon after 6.4.0
is released*, and have the new version available in 6.4.1.
Does that cause a problem?

(the version now in 6.5svn has the '-f' flag to turn on MDF)

Hamish

[*] ... can someone test if 6.4's v.surf.rst works on XP/Vista/7?

10

oh by the way, my current favourite shell script way of testing if a flag
exists (yet) in a module is not to test the version/revision, but to do a
more direct query:

  r.watershed --interface-description | grep -c '<flag name="f">'

which should return 0 or 1.

Hamish

11

On Apr 28, 2010, at 10:31 PM, Hamish wrote:

oh by the way, my current favourite shell script way of testing if a flag
exists (yet) in a module is not to test the version/revision, but to do a
more direct query:

r.watershed --interface-description | grep -c '<flag name="f">'

which should return 0 or 1.

Hamish

This won't work on Windows, however, except under msys.

Michael

12

Isaac wrote:

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.

you can have cutting-edge*, or you can have stable and robust (aka
well-tested). you can't have both. For "stable" releases it is best
to be intentionally conservative.

(* the old dumb joke is to call it bleeding-edge because the closer you
get to it the more you get sliced by it)

e.g. the nasty bug which happened when scripts used uppercase character
flags had its damage limited to development svn builds only and was
flushed out by some months of testing-time.

As long as it is planned well in advance and well defined, there is no
big problem to backport the new -f MDF flag to 6.4.x AFAIAC, just don't
do that in the last few days before release, wait a few weeks for the
next minor point version. There are a couple of other features on a
similar path for 6.4.1. (For releases after x.y.1, I would tend to be a
lot more strict about breaking the "bug fixes only" rule.)

regards,
Hamish

13

We should be able to implement the Python version of this code idea fairly easily. It looks like it might be the better method from a programming point of view, as it tests for the presence of the actual flag, rather than for a version number which will infer usage of the flag, and which could change depending upon the development branch and backporting decisions.

On Wed, Apr 28, 2010 at 10:58 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

On Apr 28, 2010, at 10:31 PM, Hamish wrote:

oh by the way, my current favourite shell script way of testing if a flag
exists (yet) in a module is not to test the version/revision, but to do a
more direct query:

r.watershed --interface-description | grep -c ‘’

which should return 0 or 1.

Hamish

This won’t work on Windows, however, except under msys.

Michael

–
Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project

isaac.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

14

Yes, I agree that “stable” releases should be a bit more conservative than the devel branch, but I also would like to see that the “stable” releases contain the best tools available at the time of release. In that regard, I am also happy to hear that the MFD capabilities of r.watershed will be backported to either the 6.4.0 or 6.4.1 releases.
For future reference, what is the protocol the devel team uses for determining such backports? ie., how does one feature become slated for a backport, while another may not? Is it by popular demand? Or by some quantitative “proof of stability”? Or something else? I’m mainly curious, as I’d like to know if there is a way for “occasional” developers like me to contribute to these decisions, either by intensive module testing, or by clamoring for a change, or by some other means. :slight_smile:

Cheers,

Isaac Ullah

On Wed, Apr 28, 2010 at 11:01 PM, Hamish <hamish_b@yahoo.com> wrote:

Isaac wrote:

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.

you can have cutting-edge*, or you can have stable and robust (aka
well-tested). you can’t have both. For “stable” releases it is best
to be intentionally conservative.

(* the old dumb joke is to call it bleeding-edge because the closer you
get to it the more you get sliced by it)

e.g. the nasty bug which happened when scripts used uppercase character
flags had its damage limited to development svn builds only and was
flushed out by some months of testing-time.

As long as it is planned well in advance and well defined, there is no
big problem to backport the new -f MDF flag to 6.4.x AFAIAC, just don’t
do that in the last few days before release, wait a few weeks for the
next minor point version. There are a couple of other features on a
similar path for 6.4.1. (For releases after x.y.1, I would tend to be a
lot more strict about breaking the “bug fixes only” rule.)

regards,
Hamish

–
Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project

isaac.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

15

I have built this functionality into the code, so r.watershed MFD functionality will be used if available, regardless of which GRASS version. However, our wired ethernet is out, so I cannot commit is to SVN until they fix that (the computer I keep the versions on does not have a wifi card). I will commit these changes to SVN as soon as the internet is restored to us!

Cheers,

Isaac

On Thu, Apr 29, 2010 at 10:15 AM, Isaac Ullah <isaac.ullah@asu.edu> wrote:

We should be able to implement the Python version of this code idea fairly easily. It looks like it might be the better method from a programming point of view, as it tests for the presence of the actual flag, rather than for a version number which will infer usage of the flag, and which could change depending upon the development branch and backporting decisions.

On Wed, Apr 28, 2010 at 10:58 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

On Apr 28, 2010, at 10:31 PM, Hamish wrote:

oh by the way, my current favourite shell script way of testing if a flag
exists (yet) in a module is not to test the version/revision, but to do a
more direct query:

r.watershed --interface-description | grep -c ‘’

which should return 0 or 1.

Hamish

This won’t work on Windows, however, except under msys.

Michael

–
Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project

isaac.ullah@asu.edu
ullah@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.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

16

[*] ... can someone test if 6.4's v.surf.rst works on XP/Vista/7?

we have been running it all semester on XP/Vista/7 without any complaints,
but I would have to specifically
check who actually ran it with GRASS installed under Program Files.
The new installer caused numerous problems (most of them were fixed already I guess)
so I am finding that most students
keep grass under C:\GRASS or something similar even after they update
and they also may have access enabled.
Some complaints included r.thin and r.lake and that they needed to define the full
path when reading txt files (e.g. with v.in.ascii or r.colors, or r.recode) from
msys/home/myname which was not needed before. I have not posted any of this
because I would like to verify whether this is still an issue but my feeling
is that with change of the installation to Program files a more systematic testing is needed
for Windows.
I can ask a student here after the finals are over, mid-May, but we need more testers
for this - perhaps post to users list?

Helena

17

Le 27/04/2010 23:59, Isaac Ullah a écrit :

Dear GRASS users/developers,

     I'm happy to announce that the Mediterranean Landscapes Dynamics Project
has released a brand new version of our landscape evolution script "
r.landscape.evol.py". It can be downloaded from the GRASS ADDONS SVN
Repository in the LandDyn directory (
http://trac.osgeo.org/grass/browser/grass-addons/LandDyn).

   "r.landscape.evol.py" calculates erosion and deposition values for a
region (DEM) given climactic (rainfall) and environmental (vegetation and
soils) conditions. It can iteratively calculate these values over multiple
time-steps, and will produce new surface DEM's for each time step (using the
previous DEM as input in the next time step). "r.landscape.evol.py" uses
process-based transport equations to calculate erosion/deposition
differently for different parts of the landscape (ie. flat areas,
hillslopes, mass movement, small channels, streams).

Hi,

Could you give me more precisions on the recursive aspect and its limits, for exemple do you think that your model could be applied to a nord europe hydrologic setting ? The testcase shown on your website is a wadi bordering the Jordan rift valley which is quite a different beast.

I'm also curious about how far back in time you did push your experiment and on the way you did extrapolate the neolithic period settings.

Regards,

MORREALE Jean Roc

18

Hi all,
I trying to use ps.output on wxpython gui. I wonder if there is a way to generate an input file directly from the Gis layer (a input file for ps.output which reads the layers loaded in the layer tree).
In the oldtcltk, the postcript plot "button" contained both the output as .ps as well as a .txt file which one could easily use and/or modify as an input file for the ps.map command. That was actually great as it allowed the user to save time to prepare the input file.

comments? help?
thank you
Francesco