[GRASS-dev] Re: [GRASS GIS] #807: r.watershed doesnt consider longer distance to diagonal neighbouring pixels

GRASS GIS trac at osgeo.org
Tue Dec 15 10:12:55 EST 2009


#807: r.watershed doesnt consider longer distance to diagonal neighbouring pixels
---------------------+------------------------------------------------------
  Reporter:  aread   |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect  |      Status:  new                      
  Priority:  major   |   Milestone:  6.4.0                    
 Component:  Raster  |     Version:  6.4.0 RCs                
Resolution:          |    Keywords:  r.watershed              
  Platform:  All     |         Cpu:  All                      
---------------------+------------------------------------------------------
Comment (by mmetz):

 Replying to [comment:3 helena]:
 > I finally had chance to look at it and it does make a significant
 difference (much more than I would have ever guessed)
 > and I think that after some more testing
 > the fix should go to the GRASS64 release as a bugfix.
 >
 > Some examples from the nc_spm_08 data set
 > 1m resolution
 > old
 >
 > http://skagit.meas.ncsu.edu/~helena/wrriwork/lakewh/flowD8dem.jpg
 >
 > new
 >
 > http://skagit.meas.ncsu.edu/~helena/grasswork/accum_5Kdiagfix.png
 >
 Hmm, that looks very much like the old results before the fix, the
 differences are probably due to floating point DEM support in grass65 and
 grass7, all versions of r.watershed before grass65 read DEMs as CELL,
 discarding any decimal places.

 The new SFD results for elev_lid792_1m in nc_spm_08 with grass7 are very
 similar to r.terraflow's SFD accumulation. I am pretty sure that all
 algorithms used in r.terraflow are properly implemented (although I
 disapprove of sink filling, I think it's done the right way). IIUC,
 r.terraflow sorts all cells descending by elevation (sort stream) and then
 distributes flow along the steepest slope (sweep stream), taking into
 account the longer distance to diagonal cells. Thus, the results for non-
 sinks should be mostly identical between the two modules.

 Here are some numbers on SFD flow direction for r.watershed in grass7:

 before the fix:

 edge direction no sink: 8302 (1.59%)[[BR]]
 diag direction no sink: 513291 (98.41%)[[BR]]
 edge out of sink: 233 (45.60%)[[BR]]
 diag out of sink: 278 (54.40%)

 after the fix:

 edge direction no sink: 241894 (46.38%)[[BR]]
 diag direction no sink: 279699 (53.62%)[[BR]]
 edge out of sink: 233 (45.60%)[[BR]]
 diag out of sink: 278 (54.40%)

 Similar for other DEMs, each percentage is somewhere in the range of >40%
 to <60%. Although the new result doesn't look as smooth as the old result
 for elev_lid792_1m, it now corrects for diagonal flow bias. Note that sink
 traversal is unaffected; that is IMHO the big strength of r.watershed.

 The fix not only affects the location of streams, the changes are also
 very prominent in areas with low flow accumulation, interesting for
 erosion modeling.

 MFD is not affected, i.e. this fix would be mostly needed by 64 because it
 doesn't have MFD. OTOH, these are drastically different results and before
 submitting to 64 I would like to do more testing to 1) make sure I have
 properly understood and implemented Chuck Ehlschlaeger's description and
 2) figure out why the correction present in grass32 was removed for
 grass4, there must have been a reason (maybe because the code did not
 exactly match the description and caused problems in special cases).

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/807#comment:7>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list