r.drain manual example not working

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

Applies to GRASS 6 and 7.

[rashadkm]

input

[rashadkm]

d.rast output

[rashadkm]

d.rast.num output

[rashadkm]

existing files' diff

[rashadkm]

new drain direction calculation routines using gmath lib

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

[mmetz]

Replying to 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.

Markus M

[mmetz]

Replying to 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.

Markus M