[GRASS-dev] r.watershed and swap memory

[Andrew Danner]

Luca,

 Are you using the same easting/northing in r.water.outlet for both the
results generated by r.watershed and terrastream? As the images show,
the flow lines are bit different in the two images and you might have to
shift the basin outlet coordinates a bit. Also, are you sure the mapping
of drainage values is correct? 

r.water.outlet/basin.h  lists two arrays for drainage

#define DRAINVAR	= {{ 7,6,5 },{ 8,-17,4 },{ 1,2,3 }}
#define UPDRAINVAR	= {{ 3,2,1 },{ 4,-17,8 },{ 5,6,7 }}

which seems to imply the mapping is either

7 6 5
8 x 4
1 2 3

or 

3 2 1
4 x 8
5 6 7

neither of which seem to correspond to your mapping

of 

7 0 1
6 x 2
5 4 3

I don't think 0 is a valid flow direction for r.water.outlet. running
r.stats on a flow direction map generated by r.watershed shows no 0
values. Some quick checking of the flow directions from r.watershed,
seems to suggest the second mapping above is correct, so try


1 = 8
2 = 7
4 = 6
8 = 5
16 = 4
32 = 3
64 = 2
128 = 1

-Andy

On Thu, 2008-03-27 at 13:40 +0100, Luca Casagrande wrote:
> I made some test using r.water.outlet with Spearfish location and
> output coming from GRASS and from TerraSTREAM:
> 
> http://www.movedigital.com/go/doktoreas/114926/grass_terrastream.jpg
> 
> The drainage map created with TerraSTREAM has been reclassified using those 
> rules:
> 
> 0=-1
> 128=1
> 1=2
> 2=3
> 4=4
> 8=5
> 16=6
> 32=7
> 64=0
> 
> As you can notice, the result are quite different and the one from TS generate 
> a really small area.
> 
> Any idea on that?
> 
> Thanks for your help
> Luca
> 
> On Thursday 27 March 2008 01:31:07 Andrew Danner wrote:
> > Luca,
> >
> >  The Terrastream direction coding for single flow direction is as
> > follows
> >
> > 1 = Water flows east
> > 2 = SE
> > 4 = S
> > 8 = SW
> > 16 = W
> > 32 = NW
> > 64 = N
> > 128 = NE
> >
> > Or pictorially
> >
> >  32  64 128
> >  16   x  1
> >   8   4  2
> >
> > In the MFD case, values do NOT represent aspects in the range 0 to 360,
> > but instead indicate sums of the directions above. Thus if water flows
> > N, S and SW, the value is 64+8+4 = 76.
> >
> > In both the SFD/MFD outputs, a value of 0 means this point is local
> > minimum and there is no flow direction.
> >
> > r.water.outlet reports:
> > drainage=name
> >         Input map: drainage direction. Indicates the "aspect" for each
> >         cell. Multiplying positive values by 45 will give the direction
> >         in degrees that the surface runoff will travel from that cell.
> >         The value -1 indicates that the cell is a depression area. Other
> >         negative values indicate that surface runoff is leaving the
> >         boundaries of the current geographic region. The absolute value
> >         of these negative cells indicates the direction of flow. This
> >         map is generated from r.watershed
> >
> > I don't know if the direction it refers to is measured from North or
> > East or if it moves clockwise or counterclockwise.
> >
> > r.slope.aspect measures ccw from east, TerraStream and TerraFlow are
> > measuring clockwise from East, and standard compass direction is
> > measured clockwise from North.
> >
> > If someone is more familiar with the r.water.outlet drainage directions,
> > it should be relatively easy to map the values 1,2,4,8,16,32,64 and 128
> > to 1 through 7.  log_2(tflow_dir)+1 will map terrastream flow directions
> > onto the range 1-7 (handling 0 is special case).
> >
> > Is there any consistent way of encoding flow direction?  TerraStream and
> > TerraFlow I believe used an encoding from Jenson and Domingue, though in
> > looking up their reference they started with 1 in the NE and moved
> > clockwise. Perhaps ESRI products used 1=E. It seems that aspect should
> > be measured clockwise in degrees from north geographically, but it makes
> > more sense to measure ccw from east trigonometrically.
> >
> > TerraStream could easily rotate or reverse the values 1-255 if there is
> > a standard out there to follow.
> >
> >
> > -Andy