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

[Moritz Lennert]

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:
>> Thanks for your answer.
>>
>>> 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