#1840: r.drain manual example not working
-------------------------+--------------------------------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Raster | Version: svn-releasebranch64
Keywords: r.drain | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
I have added the test case from the manual in r54356 in
grass70/raster/r.drain/tests/
While the manual tells that a raster line will be produced,
only the start pixel is found. Failure?
#1840: r.drain manual example not working
-------------------------+--------------------------------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Raster | Version: svn-releasebranch64
Keywords: r.drain | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mmetz):
Replying to [comment:1 rashadkm]:
> with the attached diff and drain.c it produces correct output from
r.drain. I had tested diffrent start location and it worked
>
> Only problem is output map is always of type CELL. Will it be a
problem?
Yes, it will be a problem, because the examples in the manual of r.drain
are based on a DEM, in which case the code is correct and the example is
wrong, the path should stop as soon as a border is reached or any neighbor
cell is NULL.
I have updated r.cost/r.walk/r.drain in r54417-9. r.drain can now read
GRASS standard directions, e.g. flow directions from r.watershed
(multiplied with 45 in order to get degrees CCW from East) in addition to
movement directions from r.cost/r.walk. The examples in the manual of
r.drain are fixed.
What remains to be tested and fixed is input from r.cost/r.walk where the
path reaches a border.
#1840: r.drain manual example not working
-------------------------+--------------------------------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Raster | Version: svn-releasebranch64
Keywords: r.drain | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mmetz):
Replying to [ticket:1840 neteler]:
> I have added the test case from the manual in r54356 in
> grass70/raster/r.drain/tests/
>
> While the manual tells that a raster line will be produced,
> only the start pixel is found. Failure?
The example elevation surface comes from r.drain in GRASS 3.2, or earlier.
r.drain has been changed quite a lot since then, mainly because there were
problems with the drainage directions determined by r.drain.
A first attempt to solve this problem was to clone code from another
module (r.fill.dir) in order to cope with flat areas and sinks. IMHO, the
idea was right, but the implementation was wrong: it would have been much
easier to simply allow a direction map as input for r.drain. As a side
effect of this modification, an efficient mechanism to cache input data
has been replaced with a less efficient mechanism. This change which
happened somewhere between 4.2 and 5.4 is the reason why the example as in
3.2 is no longer working.
Another problem with path directions was that r.drain was not compatible
with the Knight's move option of r.cost and r.walk. Therefore a new option
to read a direction raster map was added to r.drain, which was actually
the solution to all previous problems of r.drain, in theory. Raster maps
encoding directions are already produced by some other modules, e.g.
r.watershed (also existing since 3.2 or earlier), and the possibility to
feed these direction maps to r.drain would have produced either least cost
paths from r.cost/r.walk output or hydrological paths from e.g.
r.watershed output. Unfortunately, the encoding of directions in the
output of r.cost and r.walk is unique within GRASS and not compatible with
GRASS standard directions using degrees CCW from East. That has been fixed
in r54419.
IMHO, the cleanest solution would be to revert r.drain back to the version
of GRASS 3.2 (the earliest I have), add support for NULL cells and fp
input, and patch in the optional direction input option indir. IOW, the
task of determining reasonable path directions should be solved by other
modules, not r.drain, because the calculation of these path directions is
rather complex, see r.cost/r.walk/r.watershed/r.terraflow/r.flow. The
manual would need to emphasize that the use of a direction input map is
strongly recommended.