On Wed, Apr 1, 2009 at 7:40 PM, Paolo Cavallini <[email protected]> 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....@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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
