[GRASS-user] The algorithm r.cost is not working
markus.metz.giswork at googlemail.com
Thu Feb 23 12:02:41 EST 2012
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 &&
> 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.
More information about the grass-user