r.cost can be run with three different methods of identifying the starting point(s). One or more points (geographic coordinate pairs) can be provided as specified start_coordinates on the command line, from a vector points file, or from a raster map. All non-NULL cells are considered to be starting points.
Each x,y start_coordinates pair gives the geographic location of a point from which the transportation cost should be figured. As many points as desired can be entered by the user. These starting points can also be read from a vector points file through the start_points option or from a raster map through the start_raster option.
r.cost will stop cumulating costs when either max_cost is reached,
or one of the stop points given with stop_coordinates is reached.
Alternatively, the stop points can be read from a vector points file with the
stop_points option. During execution, once the cumulative cost to all
stopping points has been determined, processing stops.
Both sites read from a vector points file and those given on the command line
will be processed.
The null cells in the input map can be assigned a (positive floating
point) cost with the null_cost option.
When input map null cells are given a cost with the null_cost
option, the corresponding cells in the output map are no longer null
cells. By using the -n flag, the null cells of the input map are
retained as null cells in the output map.
As r.cost can run for a very long time, it can be useful to use the --v verbose flag to track progress.
The Knight's move (-k flag) may be used to improve the accuracy of the output. In the diagram below, the center location (O) represents a grid cell from which cumulative distances are calculated. Those neighbors marked with an X are always considered for cumulative cost updates. With the -k option, the neighbors marked with a K are also considered.
. . . . . . . . . . . . . . . . . . K . . K . . . . . . . . . . . . . . . . . . . . K . X . X . X . K . . . . . . . . . . . . . . . . . . . . X . O . X . . . . . . . . . . . . . . . . . . . . K . X . X . X . K . . . . . . . . . . . . . . . . . . . . K . . K . . . . . . . . . . . . . . . . . .
Knight's move example:
If the nearest output parameter is specified, the module will calculate for each cell its nearest starting point based on the minimized accumulative cost while moving over the cost map.
The solver option helps to select a particular direction in case of multiple directions with equal costs. Sometimes fields with equal cumulative costs exist and multiple paths with equal costs would lead from a start point to a stop point. By default, a path along the edge of such a field would be produced or multiple paths of equal costs with the -b flag. An additional variable can be supplied with the solver option to help the algorithm pick a particular direction.
Example for solving multiple directions:
Multiple directions can be solved as in the above example with the following steps:
If one wants r.cost to transparently cross any region of null cells, the null_cost=0.0 option should be used. Then null cells just propagate the adjacent costs. These cells can be retained as null cells in the output map by using the -n flag.
The user generates a raster map indicating the cost of traversing each cell in the north-south and east-west directions. This map, along with a set of starting points are submitted to r.cost. The starting points are put into a heap of cells from which costs to the adjacent cells are to be calculated. The cell on the heap with the lowest cumulative cost is selected for computing costs to the neighboring cells. Costs are computed and those cells are put on the heap and the originating cell is finalized. This process of selecting the lowest cumulative cost cell, computing costs to the neighbors, putting the neighbors on the heap and removing the originating cell from the heap continues until the heap is empty.
The most time consuming aspect of this algorithm is the management of the heap of cells for which cumulative costs have been at least initially computed. r.cost uses a minimum heap for efficiently tracking the next cell with the lowest cumulative costs.
r.cost, like most all GRASS raster programs, is also made to be run on maps larger that can fit in available computer memory. As the algorithm works through the dynamic heap of cells it can move almost randomly around the entire area. r.cost divides the entire area into a number of pieces and swaps these pieces in and out of memory (to and from disk) as needed. This provides a virtual memory approach optimally designed for 2-D raster maps. The amount of memory to be used by r.cost can be controlled with the memory option, default is 300 MB. For systems with less memory this value will have to be set to a lower value.
Consider the following example:
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): CUMULATIVE 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 starting location in the above example is the boxed 3 in the above input 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.
g.region raster=roads -p r.mapcalc "area.one = 1" r.cost -k input=area.one output=distance start_raster=roads d.rast distance d.rast.num distance #transform to metric distance from cell distance using the raster resolution: r.mapcalc "dist_meters = distance * (ewres()+nsres())/2." d.rast dist_meters
112.5 67.5 i.e. a cell with the value 135 157.5 135 90 45 22.5 means the next cell is to the north-west 180 x 360 202.5 225 270 315 337.5 247.5 292.5
r.cost input=costs start_raster=sources output=costsurf nearest=costalloc
Available at: r.cost source code (history)
Latest change: Monday Feb 27 13:45:25 2023 in commit: a82501dc85294207e8e58437c3ec7f1056465ed4
Main index | Raster index | Topics index | Keywords index | Graphical index | Full index
© 2003-2024 GRASS Development Team, GRASS GIS 8.4.1dev Reference Manual