If you're looking for a fast version of r.cost, try r.terracost. I think I put it at some point in the add-ons repository. Otherwise it's available from my website. Depending on the amount of memory you specify on the command line, it runs in memory (an optimized CPU algorithm) or an I/O algorithm.
-Laura
Today's Topics:
1. Re: r.cost (Markus Metz)
----------------------------------------------------------------------
Message: 1
Date: Thu, 02 Apr 2009 09:04:19 +0200
From: Markus Metz <markus.metz.giswork@googlemail.com>
Subject: Re: [GRASS-dev] r.cost
To: GRASS developers list <grass-dev@lists.osgeo.org>
Cc: cavallini@faunalia.it
Message-ID: <49D46373.4000200@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedPaolo Cavallini wrote:
Paolo Cavallini ha scritto:
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.
My comment was a suggestion to Colin Nielson to use another binary tree
in r.cost if the current tree is not a balanced tree, and that there are
generic balanced binary tree implementations in the vector libs that can
be used by other developers in their modules. AFAIKT r.cost uses the
same binary tree implementation in all versions, i.e. the results and
the speed should be similar on different machines and with different
grass versions.
