[GRASS5] r.terraflow not found...

[Laura I. Toma]

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