# [GRASS-user] The algorithm r.cost is not working

Moritz Lennert mlennert at club.worldonline.be
Thu Feb 23 05:29:21 EST 2012

On 23/02/12 07:19, Markus Metz wrote:
> On Wed, Feb 22, 2012 at 11:31 AM, Elisa Solano Villareal
> <villareal at fbk.eu>  wrote:
>>
>>> The cost surface used as input
>>> for r.cost must have only positive values, negative values will cause
>>> infinite loops. Please make sure your input cost surface has only
>>> positive values.
>>
>>   but we have seen our data and it doesn't have negative values, the minimun value is 0.
>
> I am not sure if a cost of zero is valid or if the algorithm of r.cost
> (Dijkstra search) does not allow zero costs. If you regard costs as
> e.g. travelling times, the time needed to traverse a cell, then zero
> would not be possible, because even if the time needed to traverse a
> cell is very short, it is always larger than zero.

But cost is not necessarily time. Imagine trying to evaluate the cost of
expropriation of land for a new road. Some parts of the land might
already be in the government hands and they do not have to pay for
those, but they would like to establish the cheapest route. So, allowing
for 0 cost would be a good thing, if it is not currently allowed.

...

Just tried with 6.4.2 (in nc_spm):

g.region rast=elevation
r.mapcalc "mycost=if((row()>10 && row()<100) || (col()>10 &&
col()<100),0,10)"
r.cost input=mycost at user1 output=mycumcost coordinate=630515,228182

and it works as expected. So, it doesn't seem to be a problem with 0 values.

Moritz