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

[Markus Metz]

On Thu, Feb 23, 2012 at 11:29 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> 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.

Thanks for testing! I was not sure of the algorithm used by r.cost
supports 0 costs.

Markus M