[GRASS-dev] Re: [GRASS-user] v.dissolve and r.cost problems

[Markus Neteler]

On Wed, Apr 1, 2009 at 7:40 PM, Paolo Cavallini <cavallini at faunalia.it> wrote:
> Markus Metz ha scritto:
>> Could it be that the binary tree implementation in r.cost is not
>> balanced? If yes, the search tree may degenerate on smooth surfaces
>> towards a linked list, search time going from O(log n) to O(n). BTW,
>> there are now three different generic balanced binary search tree
>> implementations in the vector libs, plus sorted heaps. Just an idea.
>
> Tested on two different machines, (ubuntu+debian) 3 diff surfaces,
> always the same result. It seems something more structural.
> :(

Or 6.3.0 is a bit old?

> But, is r.cost working for somebody else?

Yes (example from the manual page):

# Spearfish
GRASS 6.5.svn (spearfish60): > g.region rast=roads -p
projection: 1 (UTM)
zone:       13
datum:      nad27
ellipsoid:  clark66
north:      4928010
south:      4913700
west:       589980
east:       609000
nsres:      30
ewres:      30
rows:       477
cols:       634
cells:      302418
GRASS 6.5.svn (spearfish60): > r.mapcalc "area.one=1"
 100%
GRASS 6.5.svn (spearfish60): > time -p r.cost -k input=area.one
output=distance start_rast=roads
Reading raster map <area.one at neteler>...
 100%
Initializing output...
 100%
Reading raster map <roads>...
 100%
Finding cost path...
 100%
No data
Writing raster map <distance>...
 100%
r.cost complete. Peak cost value: 87.970583.
real 1.65
user 1.50
sys 0.09

1.7 seconds looks ok...

Relevant post-6.3.0 fix:

2008-07-24 06:32  martinl
* main.c: Fix calculation of number of segments (round up instead of
down) [merged from trunk, r32239]

Please send me a minimalistic location to try here...

Best
Markus