[GRASS5] RE: [GRASSLIST:2594] RE: d.area: areas filled with various colors

GRASS GRASS developer
1

Markus,

With respect to the new vector format expected in Grass5.1(?), I was
wondering if this automatic color filling is planned. When dealing with
very large vector maps we need some way to do this. At present I just
convert my map to raster and create categories. This does not create too
many problems but certainly working directly with the vectors will be
better.

Charles

-----Original Message-----
From: Markus Neteler [mailto:neteler@itc.it]
Sent: Monday, October 22, 2001 11:23 AM
To: Beaudry Charles (NORANDA)
Cc: GRASSLIST@baylor.edu; grass5 developers list
Subject: Re: [GRASSLIST:2594] RE: d.area: areas filled with various
colors

On Mon, Oct 22, 2001 at 08:59:15AM -0400, Beaudry Charles (NORANDA) wrote:

Markus,

I saw your new d.area with -f. Looks good. Does it actually read the
attribute data from the database and use some sort of look up table to
assign the colors or are the colors assigned by hand?

Charles

Hi Charles,

no, unfortunately it just cycles through the color table,
resetting to color 1 after color 13.
There is a need to develop "v.colors" in my opinion.

Markus

-----Original Message-----
From: Markus Neteler [mailto:neteler@itc.it]
Sent: Friday, October 19, 2001 12:34 PM
To: GRASSLIST@baylor.edu
Cc: grass5 developers list
Subject: [GRASSLIST:2591] d.area: areas filled with various colors

On Fri, Oct 19, 2001 at 02:32:40PM +0300, Ahmet Temiz wrote:
> Hi
>
> I'm sorry to take up your time.
> I would like to know how I can see vector polygons in different color in
Grass5.
> Say, I have geology map that has been prepared as vector polygons. and
> I have to see geo formations in differen color for interpretation.
>
>
> Kind Regards
>
> Ahmet Temiz
> Geo. Eng.
> Gen. Dir of Disaster Affairs
> TURKEY

Hi,

just now I have added "-f" to d.area to optionally draw vector polygons
with various colors. It is a simple approach just cycling through
the (still limited) color table for vector data.
See attachment for an impression (19k, hope that's o.k.).

The improvement is available in CVS and will ship with next
GRASS 5 release.

cheers

Markus Neteler
-----

This message has been scanned by the AT&T Global Network Services Virus

Detect Service.

Ce message a été scruté par le service Virus Detect des Services de

réseaux mondial AT&T.

-----

--
Markus Neteler

ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
     Project on Predictive Models for the Environment
Via Sommarive, 18 - 38050 Povo (Trento), Italia
tel +39 0461 314 -520 (fax -591) http://mpa.itc.it

2

On Mon, 22 Oct 2001 11:32:07 -0400, "Beaudry Charles (NORANDA)" <BeaudryC@normin.com> wrote:

Markus,

With respect to the new vector format expected in Grass5.1(?), I was
wondering if this automatic color filling is planned. When dealing with
very large vector maps we need some way to do this. At present I just
convert my map to raster and create categories. This does not create too
many problems but certainly working directly with the vectors will be
better.

This is more a limitation imposed by the GRASS display architechture than
anything with the vector data representation. When this limitation is
addressed, it will be trivial to modify vector display routines to use a
larger color gamut.

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

3

Eric G. Miller wrote:

> With respect to the new vector format expected in Grass5.1(?), I was
> wondering if this automatic color filling is planned. When dealing with
> very large vector maps we need some way to do this. At present I just
> convert my map to raster and create categories. This does not create too
> many problems but certainly working directly with the vectors will be
> better.

This is more a limitation imposed by the GRASS display architechture than
anything with the vector data representation.

This is a limitation imposed by vector layers not having colour
tables.

Which, I presume, is what Markus meant by:

There is a need to develop "v.colors" in my opinion.

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

4

On Tue, 23 Oct 2001 05:50:52 +0100, Glynn Clements <glynn.clements@virgin.net> wrote:

Eric G. Miller wrote:

> > With respect to the new vector format expected in Grass5.1(?), I was
> > wondering if this automatic color filling is planned. When dealing with
> > very large vector maps we need some way to do this. At present I just
> > convert my map to raster and create categories. This does not create too
> > many problems but certainly working directly with the vectors will be
> > better.
>
> This is more a limitation imposed by the GRASS display architechture than
> anything with the vector data representation.

This is a limitation imposed by vector layers not having colour
tables.

So your saying if I used R_color() to set a color, and then
subsequently performed a vector drawing command that the display
drivers would do the right thing? I was under the impression that
vector and text graphics were limited to the named colors.

programming manual:

16.9 Colors

int D_reset_colors (struct Colors *colors)
  Turns color information provided in the colors structure into color
  requests to the graphics driver. These colors are for raster graphics,
  not lines or text. See 12.10.3 Raster Color Table (p. 116) for GIS
  Library routines which use this structure.

int D_translate_color (char *name)
  Takes a color name in ascii and returns the color number for that color.
  Returns 0 if color is not known. The color number returned is for lines
  and text, not raster graphics.

Perhaps, I misunderstood these statements?

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

5

Glynn, I see you're right. Somehow, I had the mistaken idea that only the
named colors could be used for vector operations. I did a quick hack on
d.vect to accept arbitrary hex color strings, and it works! I wish I'd
known about this months ago...

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

6

Eric G. Miller wrote:

> > > With respect to the new vector format expected in Grass5.1(?), I was
> > > wondering if this automatic color filling is planned. When dealing with
> > > very large vector maps we need some way to do this. At present I just
> > > convert my map to raster and create categories. This does not create too
> > > many problems but certainly working directly with the vectors will be
> > > better.
> >
> > This is more a limitation imposed by the GRASS display architechture than
> > anything with the vector data representation.
>
> This is a limitation imposed by vector layers not having colour
> tables.

So your saying if I used R_color() to set a color, and then
subsequently performed a vector drawing command that the display
drivers would do the right thing? I was under the impression that
vector and text graphics were limited to the named colors.

You would first need to call R_reset_color() to associate an RGB value
with a colour index.

Basically:

R_reset_color() sends RESET_COLOR, receipt of which calls

  Reset_color() -> _fixed_Reset_color() -> assign_fixed_color()

which sets an entry in the {pos,neg}_color_lookup arrays.

R_reset_colors() is similar.

R_color sends COLOR, receipt of which calls

  Color() -> _get_color_index() -> get_fixed_color()

which gets an entry from the {pos,neg}_color_lookup arrays, and makes
this colour "current" for subsequent single-colour drawing operations
(i.e. not rasters) via the (driver-specific) color() function.

Raster operations also use the {pos,neg}_color_lookup arrays, via
_get_color_index_array().

The standard colours are initialised at driver startup, by the driver
calling assign_standard_color() directly, which sets an entry in the
standard_colors array.

R_standard_color() sends STANDARD_COLOR, receipt of which calls

  Standard_color() -> get_standard_color()

which gets an entry from the standard_colors array, and makes this
colour "current" for subsequent single-colour drawing operations (i.e.
not rasters) via the (driver-specific) color() function.

Also, the driver startup initialises the fixed colour indices 1-13
(corresponding to the constants in colors.h) to the standard colours
so that, unless subsequently changed, R_color() has the same effect as
R_standard_color() for the indices 1-13.

programming manual:

16.9 Colors

int D_reset_colors (struct Colors *colors)
  Turns color information provided in the colors structure into color
  requests to the graphics driver. These colors are for raster graphics,
  not lines or text. See 12.10.3 Raster Color Table (p. 116) for GIS
  Library routines which use this structure.

This function doesn't seem to exist. At least, not in
src/libes/display/*.c or src/include/display.h.

D_set_colors() does exist with that prototype; that calls
R_reset_colors(), which would affect the RGB colour selected by calls
to R_color(). However, this function probably isn't appropriate for
anything other than raster graphics.

int D_translate_color (char *name)
  Takes a color name in ascii and returns the color number for that color.
  Returns 0 if color is not known. The color number returned is for lines
  and text, not raster graphics.

This translates the string "red" to the constant RED etc. The return
values can be passed to R_standard_color(), or to R_color() provided
that the colours haven't been changed from their initial setting (but
this shouldn't be relied upon).

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

7

I've hacked on a version of d.area to support a greater range of colors
and selective drawing by categories. It's not as convenient as having
a full color/legend capability, but we can work on that. At the
moment I'm using the X11 color name database "rgb.txt", but I expect
to allow arbitrary rgb colors as well with something like:

    "fillcolor=rgb(<0-255> <0-255> <0-255>)"

Here's the help output:

GRASS> d.area help

Description:
Obtains area/perimeter information on vector polygons.
         ^^^^
          Oops, need to fix that!

Usage:
d.area [-f] map=name [fillcolor=name] [linecolor=name]
   [category=value[,value,...]]

Flags:
  -f Fill all areas with color (cycle through colors)

Parameters:
        map Name of existing vector map to be displayed
  fillcolor Color desired for filling polys (X11 color name)
              default: white
  linecolor Color desired for drawing map (X11 color name)
              default: none
   category List of area categories to display

Use it like: d.area map=mymap fill="cyan2" line="grey70" cat=1,2,5,9

At the moment, if the "-f" flag is specified, then it cycles through
the GRASS standard colors (not the X11 ones).

Probably better to use some kind of legend file so the user doesn't
have to specify these things again and again.

Comments, suggestions, flames, ...

I haven't committed the changes, if you're looking for them... Still
need some resolution on this coordinate transformation issue...

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

8

Eric G. Miller wrote:

Comments, suggestions, flames, ...

One comment: don't make it so it won't compile without X.

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