[GRASS5] testing GRASS5.0.0pre1

GRASS GIS GRASS GIS developer
,
1

Hi 2 all,

I checked out the 5.0.0pre1 tagged version from CVS (fresh checkout) and
recompiled on Linux, FreeBSD/Alpha, IRIX and Windows 2000/cygwin.

Linux (Red Hat 7.0, Kernel 2.2.17, gcc 2.96):
compiles without any problems, but could not test many
programs. Basics work (tcltkgrass, display etc.), but have to test
r.in.gdal and NVIZ 2.2.
Does someone have a set of testing data for r.in.gdal?

FreeBSD 4.2 (Alpha 64bit, gcc)
recompiles without problems, can not compile NVIZ2.2, because i
have not installed mesa/openGL.
Optimizing is not possible (removed -O2 flag!), due to bug in
gcc on FreeBSD-Alpha.
Works if i replace the wish script with a softlink to wish8.3
(How can i change the GRASS_WISH variable for my installation?).
I can confirm that it is possible to import ASCII/DXF vector files
and to manipulate them. The demo vector files are not readable due
to the 64bit environment.
Left out r.in.gdal and NVIZ 2.2.

IRIX 6.5 (32bit, latest gcc from freeware.sgi.com)
One has to remove the -I/usr/freeware/include line to gcc in order to
get any library to compile. Don't know why, but with the line the
libraries
fail to compile and nearly no modules are built.
I still use all options to ./configure, but i did not try if this is
still
needed. NVIZ 2.2 compiles and works! Great!
The only module i left out is r.in.gdal. Did not test postgresql.

Windows 2000/cygwin 1.1.8/gcc
Everything compiles out of the box (when using my compiling
instructions!).
I had a problem compiling r.mapcalc in
the first run, but could not reproduce this. With the StarNet demo
everything seems to work.
I left out r.in.gdal and NIVZ 2.2. r.in.gdal compiles, but last time i
tested it did only core-dump. NVZI does not compile, John reports that
it did
compile, but his fix does not work with my installation.
There are problems with localization libraries if installing the Windows
2000 binary (xtcltk binary) on NT 4.0. But the other way round it seems
to work. So one
should compile always on NT 4.0.
The odbc drivers compile, but i did not test anything. PostgreSQL does
not
compile on my machine, but i think that postgreSQL is not ready for
wider
use (you need a "cutting edge" cygwin1.dll and the ipc daemon installed
and
running in order to start the server part!).

The only real BUG that needs IMHO fixed for the 5.0.0stable version is
the
CELL driver problem.
The colors are sometimes wrong, but it is not always black/white that
are
changed. I have no clue.
On Windows in noticed that the CELL driver could only be started and
stopped
once, the socket is not removed, so that on restarting the driver i get
the
message "can not bind to socket...". Very annoying.
Is this a problem on Linux too? I have to check.

Minor bugs/problems (all with FreeBSD/ALPHA):

v.out.e00:
does not read vector files from other mapsets,
e. g. coastlines@PERMANENT, when in mapset andreas
Produces coredump on coastlines mapset from global5
dataset (on linux)!

v.out.arc:
not a bug, but the manual page does not mention
that the generated arc-files are stored under
$LOCATION/arc !

d.zoom (lat/lon on Alpha/FreeBSD):
does not keep color of vector file!
does not recognize that background color
was white/different from black?

d.zoom has problems with rubber-band box in lat/lon
locations?

sorry that some messages may not be clear, but i wrote this before the
easter break and my memory is fading...

cu,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Hi Andreas,

On Thu, Apr 19, 2001 at 11:51:21AM +0200, Andreas Lange wrote:

Hi 2 all,

I checked out the 5.0.0pre1 tagged version from CVS (fresh checkout) and
recompiled on Linux, FreeBSD/Alpha, IRIX and Windows 2000/cygwin.

Linux (Red Hat 7.0, Kernel 2.2.17, gcc 2.96):
compiles without any problems, but could not test many
programs. Basics work (tcltkgrass, display etc.), but have to test
r.in.gdal and NVIZ 2.2.
Does someone have a set of testing data for r.in.gdal?

maybe your try these sample data:
http://csd-esic.unl.edu/drg100.htm
(Nebraska)

r.in.gdal -e input=AINSWORTH.tif out=ainsworth location=testlocation

Start this command in any other location (as r.in.gdal only works within
GRASS), it will generate a new *location* from the dataset.

FreeBSD 4.2 (Alpha 64bit, gcc)
recompiles without problems, can not compile NVIZ2.2, because i
have not installed mesa/openGL.
Optimizing is not possible (removed -O2 flag!), due to bug in
gcc on FreeBSD-Alpha.

Sidenote:
For all not knowing this (like me until last week):
If you would like to set compiler optimisations, for a smaller binary, type,

        CFLAGS=-O2 ./configure
or,
        setenv CFLAGS -O
        ./configure

So no need to edit the head file manually. I have added this to the
INSTALL file.

Works if i replace the wish script with a softlink to wish8.3
(How can i change the GRASS_WISH variable for my installation?).

grass5 -help
Environment variables:
    GRASS_TCLSH set tclsh shell name to override 'tclsh'
    GRASS_WISH set wish shell name to override 'wish'

I can confirm that it is possible to import ASCII/DXF vector files
and to manipulate them. The demo vector files are not readable due
to the 64bit environment.
Left out r.in.gdal and NVIZ 2.2.

IRIX 6.5 (32bit, latest gcc from freeware.sgi.com) One has to remove the
-I/usr/freeware/include line to gcc in order to get any library to
compile. Don't know why, but with the line the libraries fail to compile
and nearly no modules are built.
I still use all options to ./configure, but i did not try if this is
still needed. NVIZ 2.2 compiles and works! Great!
The only module i left out is r.in.gdal. Did not test postgresql.

Doesn't r.in.gdal compile? Or why do you leave it?

Windows 2000/cygwin 1.1.8/gcc
Everything compiles out of the box (when using my compiling
instructions!).
I had a problem compiling r.mapcalc in
the first run, but could not reproduce this. With the StarNet demo
everything seems to work.
I left out r.in.gdal and NIVZ 2.2. r.in.gdal compiles, but last time i
tested it did only core-dump. NVZI does not compile, John reports that
it did compile, but his fix does not work with my installation.
There are problems with localization libraries if installing the Windows
2000 binary (xtcltk binary) on NT 4.0. But the other way round it seems
to work. So one should compile always on NT 4.0.
The odbc drivers compile, but i did not test anything. PostgreSQL does
not compile on my machine, but i think that postgreSQL is not ready for
wider use (you need a "cutting edge" cygwin1.dll and the ipc daemon
installed and running in order to start the server part!).

The only real BUG that needs IMHO fixed for the 5.0.0stable version is the
CELL driver problem. The colors are sometimes wrong, but it is not always
black/white that are changed. I have no clue.

On Windows in noticed that the CELL driver could only be started and
stopped once, the socket is not removed, so that on restarting the driver
i get the message "can not bind to socket...". Very annoying.
Is this a problem on Linux too? I have to check.

This is the timing bug which is currently addressed by Glynn and Eric.

Minor bugs/problems (all with FreeBSD/ALPHA):

v.out.e00:
does not read vector files from other mapsets,
e. g. coastlines@PERMANENT, when in mapset andreas
Produces coredump on coastlines mapset from global5
dataset (on linux)!

Hi Michel :slight_smile:

v.out.arc:
not a bug, but the manual page does not mention
that the generated arc-files are stored under
$LOCATION/arc !

Yesterday this was changed. It saves the data into the current
directory now. Just now I have added such a note in the man page.

d.zoom (lat/lon on Alpha/FreeBSD):
does not keep color of vector file!
does not recognize that background color
was white/different from black?

d.zoom has problems with rubber-band box in lat/lon
locations?

This runs well here. Maybe it is a platform specific bug?

sorry that some messages may not be clear, but i wrote this before the
easter break and my memory is fading...

Thanks for your tests!

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi guys,

FWIW, r.in.gdal works like a champ on Suse 7.1 with the 2.4.X kernels.
Compiles cleanly and runs fine (Producing useful output).

After you use r.in.gdal, please do me a favor and verify that you can use
r.patch to attach a couple images together.

I am trouble-shooting r.patch now as it produces NO output.

r.patch gets to the point where it says is will produce the support files
and then runs forever. Yesterday I let one process run for over 14 hours.
No result was produced and the temp file did not change past the first 10
minutes or so.

Any results would be nice (I really hope I am not chasing shadows).

Thanks,
Matt

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Please forgive my ignorance.

Is there some way to compile only one specific module, without compiling
most (or all) of grass? In other complex systems I have seen the ability
to go into the specific directory of that part of the system, and just
make it.

Without some fiddling, I can't do that here from what I see.

Any ideas?

Thanks,
Matt

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Thu, Apr 19, 2001 at 10:36:45AM -0400, mberglund wrote:

Please forgive my ignorance.

Is there some way to compile only one specific module, without compiling
most (or all) of grass? In other complex systems I have seen the ability
to go into the specific directory of that part of the system, and just
make it.

Without some fiddling, I can't do that here from what I see.

Any ideas?

Hi Matt,

this is described in INSTALL :slight_smile:

cd src/my/module
gmake5 -i
gmakelinks5

I have modified gmakelinks5 to a local gmakelinks5b to set the
link in /usr/local/grass5 to avoid the full "make install" process.
A -i flag for gmakelinks5 would be great...

Hope this helps,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Thu, Apr 19, 2001 at 10:12:26AM -0400, mberglund wrote:

Hi guys,

FWIW, r.in.gdal works like a champ on Suse 7.1 with the 2.4.X kernels.
Compiles cleanly and runs fine (Producing useful output).

That's nice to hear.

After you use r.in.gdal, please do me a favor and verify that you can use
r.patch to attach a couple images together.

I am trouble-shooting r.patch now as it produces NO output.

r.patch gets to the point where it says is will produce the support files
and then runs forever. Yesterday I let one process run for over 14 hours.
No result was produced and the temp file did not change past the first 10
minutes or so.

Any results would be nice (I really hope I am not chasing shadows).

Mhhh...

I just tried r.patch with a small map:

g.region -p; date ; r.patch in=areaA,areaB out=patch; date
projection: 99 (Transverse Mercator)
zone: 0
datum: potsdam
ellipsoid: bessel
north: 5772695
south: 5766875
west: 3559800
east: 3569180
nsres: 5
ewres: 5
rows: 1164
cols: 1876
Don Apr 19 17:43:43 CEST 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR patch
Don Apr 19 17:43:49 CEST 2001

2MB of cells take 6 seconds to complete (1Ghz AMD). The result is looking
well. If you patch 500+MB, probably the tmp-space is too small (although
you should get a G_malloc() error message then)?

Probably you have a region problem. Try to run
g.region rast=myrastermap -p

on every map and see if the coordinates are o.k. I am pretty sure that
r.patch works properly.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

On Thu, 19 Apr 2001, Markus Neteler wrote:

I just tried r.patch with a small map:

g.region -p; date ; r.patch in=areaA,areaB out=patch; date
projection: 99 (Transverse Mercator)
zone: 0
datum: potsdam
ellipsoid: bessel
north: 5772695
south: 5766875
west: 3559800
east: 3569180
nsres: 5
ewres: 5
rows: 1164
cols: 1876

Ok, 1164x1876, that is small.

Don Apr 19 17:43:43 CEST 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR patch
Don Apr 19 17:43:49 CEST 2001

2MB of cells take 6 seconds to complete (1Ghz AMD). The result is looking
well. If you patch 500+MB, probably the tmp-space is too small (although
you should get a G_malloc() error message then)?

If you mean "grass tmp", in the .tmp directory where my maps are, grass
has access to over 3 gigs of space.
Real memory doesn't seem to be a problem as it never creeps over about 20%
of 320M. It does consume all the processor it can get.

Having not run a GIG machine, I am not sure of how much faster it really
is, but being generous, lets assume 8x as fast (I am on a PII 300).
Assuming a patch of the entire set of files(which I am not doing, more
like 1/10th of the total by region) you would be patching 1gig of material
so your machine should process that in about 50mins, and mine in about 7
hours.

I let the thing run all night, I said 14 hours but more like 18/20 and got
no resulting files.

I think these numbers are probably an overshoot, but that still says
something is wrong.

Probably you have a region problem. Try to run

If you remember about 3 weeks ago, I was having problems with r.proj and
STP becuase the nad27 file was the only one that got read. The quick fix
as per Morten Hulden was to rename grass5/etc/nad83 to grass5/etc/nad27.
To get my material to reproject I had to perform the same thing, even
under the most current cvs check out.

Could this be affecting the situation?

g.region rast=myrastermap -p

Well, I'll try this (after I fix what I just broke).

Thanks,
Matt

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Hi Matt
(cc to grass5)

On Thu, Apr 19, 2001 at 03:14:15PM -0400, mberglund wrote:
[...]

I have set the region to only a small portion (say 2100x2500) where both
images overlap.

set r.patch off and running, with my debug, I see it running. And it has
been doing this for every over half an hour.

in support.c you will find a while loop, inside a for loop like so:
while (G_next_cell_stat (&n, &count, statf + i)){
           printf("%i\n",count); /* just to see if it is running or hung*/
           if (n && !G_find_cell_stat (n, &count, statf))
           {
              if(do_cats)
              {
                 G_update_cell_stats (&n, 1, statf);
                 G_set_cat (n, G_get_cat (n, &pcats), cats);
              }
              if(do_colr)
              {
                 G_get_color (n, &red, &grn, &blu, &pcolr);
                 G_set_color (n, red, grn, blu, colr);
              }
           }
        }
        }

What is happening in here that would take so long? You did an area about
half the pixel size mine in 6 seconds. Mine has been running for over an
hour, although, on a slower machine.

This is the loop that is holding me up.
Any thoughts?

Seems we need some test pattern (to get comparable results):
As r.mapcalc is my friend, what about (in a huge location):

r.mapcalc testA="if(row()%2., row(), null())"
r.mapcalc testB="if(col()%2., col(), null())"

BTW: the testB takes much more time to calculate. Seems GRASS is row
optimized.

Testing in 4000x4000 location:
nsres: 5
ewres: 5
rows: 4000
cols: 4000
date; r.patch in=testA,testB out=testpatch; date

Fre Apr 20 11:30:48 CEST 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fre Apr 20 11:31:40 CEST 2001

(on my 1Ghz Athlon)

d.rast testpatch -> looks o.k.

Due to above formula I have 4000 categories in each raster map.
­--------------------------------------------------------------------

Now: g.region res=1 -p
nsres: 1
ewres: 1
rows: 20000
cols: 20000
(400MB cells)

Generate first pattern:
date; r.mapcalc testA="if(row()%2., row(), null())"; date
Fre Apr 20 11:35:01 CEST 2001
EXECUTING testA = ... 100%
CREATING SUPPORT FILES FOR testA
range: 1 19999
          ^^^^^^--> shouldn't this be 20000 ( or: 0..19999)???
Fre Apr 20 11:42:33 CEST 2001

Generate second pattern:
date; r.mapcalc testB="if(col()%2., col(), null())"; date
Fre Apr 20 11:42:33 CEST 2001
EXECUTING testB = ... 100%
CREATING SUPPORT FILES FOR testB
range: 1 19999
Fre Apr 20 12:12:52 CEST 2001

Patch it:
date; r.patch in=testA,testB out=testpatch; date
Fre Apr 20 12:12:52 CEST 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fre Apr 20 12:37:17 CEST 2001

d.rast testpatch

The result seems to be o.k., howeverm there are moire patterns on the
monitor (colored squares) due to the test pattern. If I zoom in the
expected pattern is visible.

Maybe this is a test helping to identify your problem?

Note: The testpatch colr/ table is quite small:
% 1 19999
1:255:255:0 4000.6:0:255:0
4000.6:0:255:0 8000.2:0:255:255
8000.2:0:255:255 11999.8:0:0:255
11999.8:0:0:255 15999.4:255:0:255
15999.4:255:0:255 19999:255:0:0

Perhaps above test should be extended with some r.colors stuff to assign
more colors (to get a larger color table). Note: It is well known that
GRASS becomes *very* slow with more than 8000 entries in color table.

Cheers

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

On Fri, 20 Apr 2001, Markus Neteler wrote:

Seems we need some test pattern (to get comparable results):
As r.mapcalc is my friend, what about (in a huge location):

r.mapcalc testA="if(row()%2., row(), null())"
r.mapcalc testB="if(col()%2., col(), null())"

Fre Apr 20 11:30:48 CEST 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fre Apr 20 11:31:40 CEST 2001

Test 1:

Fri Apr 20 09:37:05 EDT 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fri Apr 20 09:39:36 EDT 2001

Yes, your machine is about 3 time faster than mine (stands to reason).

I am working on test two, but it is going to take a while.

Now, this is interesting. I have a color table of only 1 entry, for each
of the input files (on my original data) and for my category files.

COLRS:
matt@europa:~/GIS/maps/marion/sp/colr > cat 4117se1
% 0 16581375
0:0 16581375:255
matt@europa:~/GIS/maps/marion/sp/colr > cat marion
% 0 16581375
0:0 16581375:255

CATS:
matt@europa:~/GIS/maps/marion/sp/cats > cat 4117se1
# 16581375 categories

0.00 0.00 0.00 0.00
matt@europa:~/GIS/maps/marion/sp/cats > cat marion
# 16581375 categories

0.00 0.00 0.00 0.00

But in the patch I had a 830KB cat file! The color file was also large.

Perhaps above test should be extended with some r.colors stuff to assign
more colors (to get a larger color table). Note: It is well known that
GRASS becomes *very* slow with more than 8000 entries in color table.

Is grass also slow to create the colors? And does it stand to reason that
a larger number of categories implys a larger color palete.

I ran r.support on the patch file before this conversation, so the only
thing I can tell you is that the color file was big, and the categories
file was 830KB.

When I import my tiffs (using r.in.gdal) I have to run r.support to get
the grey scaled image I require. When I give it the color count, am I
giving it too many colors to work with? I am working from 24 bit tiffs.

Thanks for all the help, as soon as I am done with test 2, I'll pipe up.

Thanks,
Matt

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Ok, the test results are in.

Test 1:

Fri Apr 20 09:37:05 EDT 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fri Apr 20 09:39:36 EDT 2001

Test 2:
g.region res=1 -p
nsres: 1
ewres: 1
rows: 20000
cols: 20000

GRASS:~ > date; r.mapcalc testA="if(row()%2., row(), null())"; date
Fri Apr 20 09:44:40 EDT 2001
EXECUTING testA = ... 100%
CREATING SUPPORT FILES FOR testA
range: 1 19999
Fri Apr 20 10:04:48 EDT 2001

GRASS:~ > date; r.mapcalc testB="if(row()%2., row(), null())"; date
Fri Apr 20 10:06:15 EDT 2001
EXECUTING testB = ... 100%
CREATING SUPPORT FILES FOR testB
range: 1 19999
Fri Apr 20 10:29:08 EDT 2001

Fri Apr 20 10:33:34 EDT 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fri Apr 20 11:05:47 EDT 2001

Well, there you go. I am not sure what this proves. But what I do believe
is the color issue is hurting me. for the area covered, the times seem
reasonable.

Does this mean grass is not well suited to my application (patching lots
of images over a large area) or does this mean that I am doing something
wrong with the images?

I am glad r.patch works, now I need to figure out how to achieve my goal.

Any advise or ideas would be useful.

Thanks again,
Matt

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

On Fri, Apr 20, 2001 at 10:07:51AM -0400, mberglund wrote:
[...]

But in the patch I had a 830KB cat file! The color file was also large.

Mhhh, the color/cat patch seems to be poor in r.patch (therefore we
have i.image.mosaik as a workaround). It should become better once...

> Perhaps above test should be extended with some r.colors stuff to assign
> more colors (to get a larger color table). Note: It is well known that
> GRASS becomes *very* slow with more than 8000 entries in color table.

Is grass also slow to create the colors? And does it stand to reason that
a larger number of categories implys a larger color palete.

I guess it is a color sort problem or so.

Have a look here on former threads:
http://www.geog.uni-hannover.de/mailinglisten/grass5/archive/2001/3/24/2
http://www.geog.uni-hannover.de/mailinglisten/grass5/archive/2001/3/9/11
http://www.geog.uni-hannover.de/cgi-bin/minorweb.pl?A=READ&L=grass5/2001/3/8/24
http://www.geog.uni-hannover.de/cgi-bin/minorweb.pl?A=READ&L=grass5/2001/3/9/4

If you look at r.in.tiff you will see some logic to reduce colors.

Maybe you can dig into all this?

Thanks,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

On Fri, Apr 20, 2001 at 11:30:28AM -0400, mberglund wrote:

Ok, the test results are in.

Test 1:

Fri Apr 20 09:37:05 EDT 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fri Apr 20 09:39:36 EDT 2001

Test 2:
g.region res=1 -p
nsres: 1
ewres: 1
rows: 20000
cols: 20000

GRASS:~ > date; r.mapcalc testA="if(row()%2., row(), null())"; date
Fri Apr 20 09:44:40 EDT 2001
EXECUTING testA = ... 100%
CREATING SUPPORT FILES FOR testA
range: 1 19999
Fri Apr 20 10:04:48 EDT 2001

GRASS:~ > date; r.mapcalc testB="if(row()%2., row(), null())"; date
Fri Apr 20 10:06:15 EDT 2001
EXECUTING testB = ... 100%
CREATING SUPPORT FILES FOR testB
range: 1 19999
Fri Apr 20 10:29:08 EDT 2001

Fri Apr 20 10:33:34 EDT 2001
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR testpatch
Fri Apr 20 11:05:47 EDT 2001

Well, there you go. I am not sure what this proves. But what I do believe
is the color issue is hurting me. for the area covered, the times seem
reasonable.

At least r.patch is working :slight_smile:

Does this mean grass is not well suited to my application (patching lots
of images over a large area) or does this mean that I am doing something
wrong with the images?

I am glad r.patch works, now I need to figure out how to achieve my goal.

Any advise or ideas would be useful.

Now let's have some fun with colors:

We have generated these maps as FP. To use r.colors' random function it
must be INT:

r.mapcalc testA2="round(testA)"
r.colors testA2 col=random
cd $LOCATION/colr
cat testA2
wc -l testA2

etc. This should result in a large color table (nice for further debugging).

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'