[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows

Markus Metz markus.metz.giswork at googlemail.com
Fri Jul 9 12:58:42 EDT 2010


[reply outside tracker because not part of original ticket]

>
> Comment(by hamish):
>
>  Replying to [comment:37 mmetz]:
>  > Well, then we have to change the way modules are presented in the menus.
>
>  [aside] can we have a README.howto file in the gui/wxpython/xml/ dir?
>  Every time I edit menudata.xml it seems to get overwritten some time later
>  by an automated update which I don't see documented anywhere. It sort of
>  kills my motivation to work on improving the menus anymore. tx.
>
Weird. Maybe Martin knows more about it.
>
>
>  > The mingw32 version of stream_len() does not work 100%,
>
>  could you explain for us humble c++ students?
>
Premature conclusion from my side. The patch for stream_len() looks ok
to me, but something went wrong in filldepr.cc lines 131-132:
boundaryStr->seek(0) must be called *after* boundaryStr->stream_len(),
otherwise it did not work for me. The reason is unclear to me, maybe a
combination of gcc 3.4.5 (mingw-vista special r3) and -O2 (grass
default it seems). Or anything else, wild guess is that file stream
handling got mixed up.

>
>  I'd rather you got together with Andrew and/or Laura and co-authored a
>  journal article racing^W comparing the two with the current offerings from
>  the other major proprietary GISs. :-) [seriously]
>
>  http://www.cs.duke.edu/geo*/terraflow/speedup.html
>
In extreme situations, r.terraflow will be faster than r.watershed in
disk swap mode, but not that much I bet. In everyday situations,
r.watershed in disk swap mode can be faster than r.terraflow mainly
because its intermediate files are much smaller and can partially be
cached by the system.

I am interested in a reasonably fast r.watershed that can handle
massive datasets and produces the most realistic results possible.
>
>  Are the core r.watershed algorithms by Ehlschlaeger any more modern? or
>  have you now replaced and upgraded them to 'state of the art'? (whatever
>  that means)

IMHO, the ingenious part is the A* Search as implemented by Chuck
Ehlschlaeger over the whole DEM. My main modification of A* Search was
adding a fast priority queue to the search. There are lots of methods
out there to remove depressions, but in my experience A* Search
produces the most realistic results. There are also lots of flow
distribution algorithms out there, but as for sink treatment, there is
AFAICT no widely accepted golden solution. I settled for something
from 1994 and modified it a bit.
>
>
>  > > > r.terraflow and iostream is written for Linux,
>
>  well I knew a version for Arc existed, so thought it possible,
>  http://wwwmath1.uni-muenster.de:8010/u/jan/TerraFlowExtension/
>
Didn't look at the source code.

Markus M


More information about the grass-dev mailing list