Solution - Re: Why are r.patch'ed files so slooowwww?

Simon Cox S.Cox at solo.ned.dem.csiro.au
Wed Jun 28 08:00:00 EDT 1995


At 11:26 AM 27/6/95 -0500, James Darrell McCauley wrote:
>Simon Cox (S.Cox at solo.ned.dem.csiro.au) writes on 27 June 1995:
>>What is the story here?  any ideas?
>
>is the composite compressed and the others not? just a guess.

I found the problem.  It is not a compression issue (that was one
of the first things I tested).

It is because r.patch attempts to preserve the original _colors_
from the input maps in some way.  This leads to a huge colr table
if there are a lot of cats.  I just deleted the colr table and it
works OK.  I am now going to hack r.patch to make this color preservation
an _option_ (and _not_ the default one either! -
as well as the problems displaying, generating this color table
within r.patch takes several times longer than doing the rest of
the patch, for my maps!).

(NB.  Bill Hargrove also suspected the color table.)

Cheers everyone                 Simon

___________________________________________________________
Dr Simon Cox                          __  \
CSIRO Exploration & Mining         ,~'  L_|\    Australian
39 Fairway, PO Box 437,         ;-'         \   Geodynamics
Nedlands, WA  6009  Australia   (            \  Cooperative
      Phone +61 9 389 8421      +    ___     /  Research
      Fax   +61 9 389 1906       L~~'   "\__/   Centre
simon at ned.dem.csiro.au                     W
AGCRC info>>   http://www.dem.csiro.au/simon/crc/intro.html
___________________________________________________________







More information about the grass-user mailing list