[GRASS5] r.terraflow

[Helena]

Glynn,

as I understand it the changes in the Gmakefile were made in response to 
Aleksey's email (see below). The tar-ball that I gave to Markus is the 
one from June that Laura refers to in her message, while the version in 
the CVS is couple months older and supposedly had the problem compiling 
on Mandrake. If the current Gmakefile is better than the new one then of 
course it should stay.

I am cc this to Laura, hopefully she will be able to advice us on this.

Helena


Glynn wrote:

Don't update the Gmakefile; the one in CVS is correct (well, it isn't
correct, but it's an improvement over the updated version).

Laura I. Toma wrote:
> Dear Aleksey,
> 
> Thanks for your feedback. I asnwered some of your comments below. We'll
> try to make the html page clearer.
> 
> I put a new tar-ball at
> http://www.cs.duke.edu/~laura/bin/
> -Laura
> 
> 
> On Thu, 12 Jun 2003, Aleksey Naumov wrote:
> 
> 
>>Dear Helena and Laura,
>>
>>Thank you for the great work on r.terraflow! It seems fast and well done. I
>>checked out version 1.5 and here is some feedback.
>>
>>Ver. 1.5 compiled fine on my Mandrake 9.1 (GCC 3.2.2), with CVS GRASS, however
>>I had to do some manual editing. Specifying --with-cxx configure option was
>>not enough, I got "Compilation error in module: src.contrib/DUKE/r.terraflow
>>(ignored)".
>>The problem was with file paths in IOStream/lib/src/*.d files which are set
>>for a RedHat system. Once I changed redhat-specific paths to their mandrake
>>equivalents:
>>	(a) /usr/lib/gcc-lib/i386-redhat-linux/3.2  =>
>>		/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2
>>	(b) /usr/include/c++/3.2/i386-redhat-linux  =>
>>		/usr/include/c++/3.2.2/i586-mandrake-linux-gnu
>>everything compiled ok. I suppose this sort of thing will require more
>>C++-specific configure checks which probably won't be really needed until
>>5.1.
>>
> 
> 
> 
> the *.d files in IOSTREAM are generated automatically. my mistake
> not to clean up before making the tar ball. Should work if you delete them
> and try compiling again from scratch.
> 
> 
> 
> 
>>The rest of this is mostly about the HTML document page, with some general
>>questions/suggestions...
>>
>>1. The "elev" argument is incorrectly documented as "elevin"
>>
> 
> fixed.
> 
> 
> 
> 
>>2. The HTML page seems confusing to me in the part explaining flooding and
>>sinks:
>>	(a) "swatershed" output is described as "output sink-watershed raster", yet
>>what it really seems to hold is a map of subwatersheds. Using "sink" is
>>really confusing here, since it most commonly means a point from which there
>>is no outflow (and this is how sinks are described in the text just above --
>>as "areas that do not spill out"). Why not call it "watershed" and describe
>>as a map that holds small subwatersheds?
>>
>>	(b) BTW, what controls the size of those subwatersheds saved in the
>>"swatershed" map? (Something similat to "threshold" in r.watershed may be
>>nice...)
>>
> 
> 
> In Terraflow the watershed of a sink represents the *entire* area that
> flows into the sink.  Basically each sink-watershed represents a bucket in
> the ground that will fill with water when it rains (long enough). Each
> sink-watershed is well-defined, and does not depend on the choice of a
> threshold. Selecting all the sinks in the terrain and computing their
> watersheds defines a partition of the terrain into sink-watersheds.
> 
> In general a watershed can be defined by an outlet point. Depending on how
> the outlet point is chosen, the  watershed is larger or smaller.
> r.watershed solves a more general problem of partitioning the terrain
> into watersheds of arbitrary outlets (not necessarily sinks) and of a
> given (approximate) size.  The problem is how to choose the  outlets
> in order to have the watersheds define a partition and have approximately
> the specified size. This is a different problem that computing
> flow direction and flow accumulation. r.terraflow does not do that (yet)
> -- but we are working on extending it with this functionality.
> 
> 
> 
> 
>>	(c) "Flooding produces a sink-less terrain in which every cell has a
>>downslope flow path leading outside the terrain ..." -- Does this mean that
>>all internal no-outlet subbasins (like catchment of a no-outlet lake) are
>>filled in?
>>
> 
> 
> Depends what you mean by "filled in".  There are 2 options:
> (1) either water (and thus flow direction) stops in sinks
> (2) or water escapes the sink by going upslope.  If the water goes
> upslope, then it follows the lowest path to the edge of the terrain.
> We think of flooding (filling the sink-watersheds) as a technique for
> finding  lowest paths and assiging upslope flow directions.  That is,
> one can assign downslope FD on the flooded terrain and map them back onto
> the  original terrain. It does not mean that the terrain has actually been
> flooded.
> 
> 
> 
> 
> 
>>	(d) I used a float DEM and my output flooded (I think it's clearer to call it
>>sinkless or depressionless) DEM is a CELL. Why not FCELL, for computational
>>and storage reasons?
>>
> 
> yes. we did not expect that the flooded terrain would be actually used.
> 
> 
> 
>>I hope I don't come accross as nagging or unappreciative! You've done a great
>>work, I just thought I'd put in my 0.05c :-)
>>
>>Thank you,
>>Aleksey
>>
>>On Monday 09 June 2003 06:54 pm, Helena wrote:
>>
>>>The new version that compiles under gcc3.2 is at
>>>http://www.cs.duke.edu/~laura/bin/
>>>
>>>I did not have time to try it out and submit it,
>>>so if you can test this latest version that would help. Also, let us
>>>know if you
>>>have any questions - it is still a work in progress.
>>>Glynn is right that it belongs to the GRASS development version and
>>>the previous version of r.terraflow is in src.contrib/DUKE
>>>
>>>
>>>Helena
>>
>>