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.gisw...@googlemail.com>
Subject: Re: [GRASS-dev] r.cost
To: GRASS developers list <grass-dev@lists.osgeo.org>
Cc: cavall...@faunalia.it
Message-ID: <49d46373.4000...@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Paolo 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.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
