Alternately, the user can simply type r.cost on the command line, without program arguments. In this case, the user will be prompted for parameter values using the standard GRASS parser interface.
r.cost can be run with two different methods of identifying the starting point(s). One or more points (geographic coordinate pairs) can be provided on the command line. In lieu of command line coordinates, the output map (e.g., output) is presumed to contain starting points. All non-zero cells are considered to be starting points. Beware: doing this will overwrite output with the results of the calculations. If output does exist and points are also given on the command line, the output is ignored and the coordinates given on the command line are used instead.
. . . . . . . . . . . . . . . . . . K . . K . . . . . . . . . . . . . . . . . . . . K . X . X . X . K . . . . . . . . . . . . . . . . . . . . X . O . X . . . . . . . . . . . . . . . . . . . . K . X . X . X . K . . . . . . . . . . . . . . . . . . . . K . . K . . . . . . . . . . . . . . . . . .
Input: COST SURFACE . . . . . . . . . . . . . . . . 2 . 2 . 1 . 1 . 5 . 5 . 5 . . . . . . . . . . . . . . . . . 2 . 2 . 8 . 8 . 5 . 2 . 1 . . . . . . . . . . . . . . . . . 7 . 1 . 1 . 8 . 2 . 2 . 2 . . . . . . . . . . . . . . . . . 8 . 7 . 8 . 8 . 8 . 8 . 5 . . . . . . . . . . . _____ . . . 8 . 8 . 1 . 1 . 5 | 3 | 9 . . . . . . . . . . . |___| . . . 8 . 1 . 1 . 2 . 5 . 3 . 9 . . . . . . . . . . . . . . . . Output (using -k): Output (not using -k): COST SURFACE CUMULATIVE COST SURFACE . . . . . . . . . . . . . . . . . . . * * * * * . . . . . . . 21. 21. 20. 19. 17. 15. 14. . 22. 21* 21* 20* 17. 15. 14. . . . . . . . . . . . . . . . . . . . * * * * * . . . . . . . 20. 19. 22. 19. 15. 12. 11. . 20. 19. 22* 20* 15. 12. 11. . . . . . . . . . . . . . . . . . . . . . * * * * * . . . . . 22. 18. 17. 17. 12. 11. 9. . 22. 18. 17* 18* 13* 11. 9. . . . . . . . . . . . . . . . . . . . . . * * * * * . . . . . 21. 14. 13. 12. 8. 6. 6. . 21. 14. 13. 12. 8. 6. 6. . . . . . . . . . . _____ . . . . . . . . . . . . . . . . . . 16. 13. 8. 7. 4| 0| 6. . 16. 13. 8. 7 . 4. 0. 6. . . . . . . . . . . |___| . . . . . . . . . . . . . . . . . . 14. 9. 8. 9. 6. 3. 8. . 14. 9. 8. 9 . 6. 3. 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .The user-provided ending location in the above example is the boxed 3 in the left-hand map. The costs in the output map represent the total cost of moving from each box ("cell") to one or more (here, only one) starting location(s). Cells surrounded by asterisks are those that are different between operations using and not using the Knight's move (-k) option. This output map can be viewed, for example, as an elevation model in which the starting location(s) is/are the lowest point(s). Outputs from r.cost can be used as inputs to r.drain, in order to trace the least-cost path given in this model between any given cell and the r.cost starting location(s). The two programs, when used together, generate least-cost paths or corridors between any two map locations (cells).
Sometimes, when the differences among cell category values in the r.cost cumulative cost surface output are small, this cumulative cost output cannot accurately be used as input to r.drain (r.drain will output bad results). This problem can be circumvented by making the differences between cell category values in the cumulative cost output bigger. It is recommended that, if the output from r.cost is to be used as input to r.drain, the user multiply the input cost surface map to r.cost by the value of the map's cell resolution, before running r.cost. This can be done using r.mapcalc or other programs. The map resolution can be found using g.region.