[GRASS5] r.terraflow

[Laura Toma]

I am not sure I understand what the problem is.. This is the update 
about r.terraflow:
-version 1.4 does not compile with gcc3.2.
-version 1.5 does.
-functionality is the same, some files in 1.5 have changed to gcc3.2 
requirements
-the only difference in the Gmakefiles  is that 1.5 contains the 
additional compile flag Wno-deprecated
-both versions tar-balls can be found at
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.4.tar.gz 
<http://www.cs.duke.edu/geo*/terraflow/terraflow-grass.html>
http://www.cs.duke.edu/geo*/terraflow/r.terraflow.1.5.tar.gz 
<http://www.cs.duke.edu/geo*/terraflow/terraflow-grass.html>

I downloaded grass-5.0.3rc2 and it looks like it contains version 1.4. 
Is there a reason for this? If not, it should be updated.  It would be 
simpler if I had CVS rights, but I never got around to doing that..sorry.

-Laura

Helena wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20030917/5054da15/attachment.html