[GRASS5] d.vect.area

GRASS GRASS developer
1

Date: Thu, 31 Jan 2002 08:02:55 -0800
From: "Eric G. Miller" <egm2@jps.net>
To: grass5@grass.itc.it
Subject: Re: [GRASS5] d.vect.area

I, personally, wanted to be able to save a color scheme after
deciding on it, and be able to easily reuse it. That's the main
reason (selfish, I know). I might be talked into the "catnum"
argument, but that approach isn't very amenable to more than
a few categories (there's a limit on command line argument
length). Also, I'd think about having your script generate a
"legend" file that the user could save for reuse. Besides,
the performance hit of generating even a temporary file is
probably insubstantial compared to iterating through the
dataset multiple times to draw each color. Color lookups
in d.vect.area should be pretty fast even for a very
large number of categories (unlike the raster color lookups,
I'm using a balanced tree which scales well).

As you could see from the other mails, Glynn convinced me of your approach. So, here's a new
version of d.area.class (or whatever we should call it).

It now has two more optional parameters :

Usage: d.area.class map=name catfile=name
classes=boundary1[,boundary2,..] [colfile=name] [reclass=name]"

Parameters:
           map = vector map to display
       catfile = variable file with 2 columns seperated by
whitespace: 1=category 2=variable by which to class
       classes = class boundaries separated by comma (but no
whitespaces), starting with boundary between class 1 and 2 and ending
with boundary between class max-1 and max
       colfile = name of the file into which you wish to save the
color legend file
       reclass = name of the file into which you wish to save the
reclass rules

So, if the user gives a 'colfile' parameter, the script will store
the color legend in the given file name, and if she/he gives a
'reclass', the script will create a reclass rules file on the basis
of the class boundaries given.

I was also thinking about creating some palettes for the
"random" color option (and perhaps making it really random).
The standard GRASS colors are fairly boring.

Is it possible to access the predefined palettes (greyscales, red to green, etc) from the shell ?
And if not, how are they implemented (i.e. how to create color scale dynamically depending on
the number of categories) ? A hint to the relevant places in the source code would be enough.

BTW, does anyone find this script useful ? I've always found the reclassifation a bit tedious,
especially when you just want to quickly test some class boundaries.

I'm presently planning a script/module that would actually decide on the class boundaries for the
user according to certain indications, such as number of classes and type of classification (i.e.
natural breaks, arithmetic, geometrical, etc). I will soon receive some fortran code implementing
this, so I'll try to reimplement it in C. Something to try my programming on without hurting
anyone too much :wink:

Moritz

2

I've modified d.vect.area a little. Two things may be of interest to you.
One is the possibility of specifying the "legend" file via standard
input by using "legend=-". The other is the addition of boundary line
drawing. The legend file is backwards compatible, with line colors
being specified as a second set of RGB values:

<cat> R G B [ R G B ]
24 255 255 255 139 139 139
48 255 0 0

Also, the legend file can now contain comments and blank lines.

There's no way to specify a default boundary color without specifying
a default fill color.

Other changes:

"-r" now is really a randomized selection from a small color palette. Always
draws boundaries in black. Fill colors are never black or white. Otherwise,
very similar to standard GRASS colors.

linecolor : corresponding boundary color argument if "color" is used for
a constant fill color.

--
Eric G. Miller <egm2@jps.net>

3

Eric G. Miller wrote:

I've modified d.vect.area a little. Two things may be of interest to you.
One is the possibility of specifying the "legend" file via standard
input by using "legend=-".

Warning: if you do this, you need to massage the command string which
is passed to D_add_to_list().

--
Glynn Clements <glynn.clements@virgin.net>

4

On Mon, 4 Feb 2002 01:00:01 +0000, Glynn Clements <glynn.clements@virgin.net> wrote:

Eric G. Miller wrote:

> I've modified d.vect.area a little. Two things may be of interest to you.
> One is the possibility of specifying the "legend" file via standard
> input by using "legend=-".

Warning: if you do this, you need to massage the command string which
is passed to D_add_to_list().

Massage how? I do see the problem though. Maybe I should take that out?

--
Eric G. Miller <egm2@jps.net>

5

Eric G. Miller wrote:

> > I've modified d.vect.area a little. Two things may be of interest to you.
> > One is the possibility of specifying the "legend" file via standard
> > input by using "legend=-".
>
> Warning: if you do this, you need to massage the command string which
> is passed to D_add_to_list().

Massage how? I do see the problem though. Maybe I should take that out?

Well, d.text does this:

        wind_file_name = G_tempfile();

  <copy data from stdin to temp file as it is processed>

  max_buff = G_malloc(strlen(wind_file_name)+strlen(G_recreate_command())+4);
  sprintf(max_buff, "%s < %s", G_recreate_command(), wind_file_name);
  D_add_to_list(max_buff);
  G_free(max_buff);

Temporary files are cleaned up at session exit, so they should remain
around long enough for XDRIVER redraws. However, scripts created with
d.save wouldn't work in subsequent sessions.

In a sense, d.text is a special case, as reading the text from stdin
was the historical behaviour.

Also, regardless of whether a given command has explicit support for
reading from stdin, a user could still use "/dev/stdin", with the same
consequences.

--
Glynn Clements <glynn.clements@virgin.net>