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.gisw...@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 <mlenn...@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 >> <villar...@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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user