[GRASS-user] The algorithm r.cost is runing now and I have a question

GRASS GRASS user
1

Than you so much.
I could run the algorithm r.cost on GRASS 6.4.1. without value (0).
But now, I am wondering why GRASS use the algorithm (Dijkstra search) for r.cost as ArcGIS.
My question... Is (Dijkstra search) the best algorithm to do it?.
I appreciate your answer,
Elisa
________________________________________
From: Markus Metz [markus.metz.giswork@googlemail.com]
Sent: Thursday, February 23, 2012 6:02 PM
To: Moritz Lennert
Cc: Elisa Solano Villareal; grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] The algorithm r.cost is not working

On Thu, Feb 23, 2012 at 11:29 AM, Moritz Lennert
<mlennert@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@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@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