[GRASS-dev] Re: grass-dev Digest, Vol 36, Issue 4

[Laura Toma]

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 at googlemail.com>
> Subject: Re: [GRASS-dev] r.cost
> To: GRASS developers list <grass-dev at lists.osgeo.org>
> Cc: cavallini at faunalia.it
> Message-ID: <49D46373.4000200 at 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.
>