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

Elisa_Solano_Villare · February 14, 2012, 10:56am

Hi there,

I have a question, I am working with r.cost algotithm but is not running for my whole spatial data but when a put just a piece of the map it works.

The main problem is that the algorithm does not finish, but it seems as keeping running 112%, 115%,120%...

My version is 6.4 and the bigest cost raster size is 6085, 6823 for the starting points are 1727.

Grass showed also this message: Dev note: Adapted sites library used for vector points. (module should be updated to GRASS 6 vector library). As the matter of fact, we are no sure if it is the real problem.

Thanking in advance,
Elisa

Markus_GRASS · February 14, 2012, 11:39am

On Tue, Feb 14, 2012 at 11:56 AM, Elisa Solano Villareal
<villareal@fbk.eu> wrote:

Hi there,

I have a question, I am working with r.cost algotithm but is not running for my whole spatial data but when a put just a piece of the map it works.

The main problem is that the algorithm does not finish, but it seems as keeping running 112%, 115%,120%...

My version is 6.4 and the bigest cost raster size is 6085, 6823 for the starting points are 1727.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible. 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. If the problem persists, it would be great if you
could provide a sample script and/or sample data to reproduce the
problem. At least in 6.4.2 r.cost is working fine.

Grass showed also this message: Dev note: Adapted sites library used for vector points. (module should be updated to GRASS 6 vector library). As the matter of fact, we are no sure if it is the real problem.

No, this is not a problem.

Markus M

Elisa_Solano_Villare · February 22, 2012, 10:31am

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.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible.

We did it but.. we found this message r.cost: malloc.c:4471: _int_malloc: Assertion '(bck->size & 0x4) == 0' failed.

Please, can you give more information.

Thanking you in advance,

Elisa

________________________________________
From: Markus Metz [markus.metz.giswork@googlemail.com]
Sent: Tuesday, February 14, 2012 12:39 PM
To: Elisa Solano Villareal
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] The algorithm r.cost is not working

On Tue, Feb 14, 2012 at 11:56 AM, Elisa Solano Villareal
<villareal@fbk.eu> wrote:

Hi there,

I have a question, I am working with r.cost algotithm but is not running for my whole spatial data but when a put just a piece of the map it works.

The main problem is that the algorithm does not finish, but it seems as keeping running 112%, 115%,120%...

My version is 6.4 and the bigest cost raster size is 6085, 6823 for the starting points are 1727.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible. 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. If the problem persists, it would be great if you
could provide a sample script and/or sample data to reproduce the
problem. At least in 6.4.2 r.cost is working fine.

Grass showed also this message: Dev note: Adapted sites library used for vector points. (module should be updated to GRASS 6 vector library). As the matter of fact, we are no sure if it is the real problem.

No, this is not a problem.

Markus M

Markus_GRASS · February 23, 2012, 6:19am

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.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible.

We did it but.. we found this message r.cost: malloc.c:4471: _int_malloc: Assertion '(bck->size & 0x4) == 0' failed.

Please, can you give more information.

I would need the input cost surface, the starting points, and the
exact command used in order to reproduce the problem.

Markus M

Thanking you in advance,

Elisa

________________________________________
From: Markus Metz [markus.metz.giswork@googlemail.com]
Sent: Tuesday, February 14, 2012 12:39 PM
To: Elisa Solano Villareal
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] The algorithm r.cost is not working

On Tue, Feb 14, 2012 at 11:56 AM, Elisa Solano Villareal
<villareal@fbk.eu> wrote:

Hi there,

I have a question, I am working with r.cost algotithm but is not running for my whole spatial data but when a put just a piece of the map it works.

The main problem is that the algorithm does not finish, but it seems as keeping running 112%, 115%,120%...

My version is 6.4 and the bigest cost raster size is 6085, 6823 for the starting points are 1727.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible. 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. If the problem persists, it would be great if you
could provide a sample script and/or sample data to reproduce the
problem. At least in 6.4.2 r.cost is working fine.

Grass showed also this message: Dev note: Adapted sites library used for vector points. (module should be updated to GRASS 6 vector library). As the matter of fact, we are no sure if it is the real problem.

No, this is not a problem.

Markus M
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

mlennert · February 23, 2012, 10:29am

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.

Moritz

Markus_GRASS · February 23, 2012, 5:02pm

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

Markus_GRASS · February 23, 2012, 5:05pm

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.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible.

We did it but.. we found this message r.cost: malloc.c:4471: _int_malloc: Assertion '(bck->size & 0x4) == 0' failed.

Can you try r.cost with percent_memory=30 (default is 100)?

Markus M

Please, can you give more information.

Thanking you in advance,

Elisa

________________________________________
From: Markus Metz [markus.metz.giswork@googlemail.com]
Sent: Tuesday, February 14, 2012 12:39 PM
To: Elisa Solano Villareal
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] The algorithm r.cost is not working

On Tue, Feb 14, 2012 at 11:56 AM, Elisa Solano Villareal
<villareal@fbk.eu> wrote:

Hi there,

I have a question, I am working with r.cost algotithm but is not running for my whole spatial data but when a put just a piece of the map it works.

The main problem is that the algorithm does not finish, but it seems as keeping running 112%, 115%,120%...

My version is 6.4 and the bigest cost raster size is 6085, 6823 for the starting points are 1727.

r.cost has changed a bit lately, in particular since GRASS version
6.4.0. Please use 6.4.2 if possible. 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. If the problem persists, it would be great if you
could provide a sample script and/or sample data to reproduce the
problem. At least in 6.4.2 r.cost is working fine.

Grass showed also this message: Dev note: Adapted sites library used for vector points. (module should be updated to GRASS 6 vector library). As the matter of fact, we are no sure if it is the real problem.

No, this is not a problem.

Markus M
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user