[GRASS5] d.vect -a|c for all types ver2

[Hamish]

Hi, just some thoughts re 'd.vect -a' for all feature types-

after this patch is merged I would like to add a d.vect rgb_column=
option to set the column name to something other than GRASSRGB (although
that will be the default).

I collect a number of channels of data along my gps tracks (water
temperature, chemistry, life, clarity, etc) and for each variable
calculate a max/min and then fit a color scale which is written as a db
column during post-processing, before the whole thing is loaded into
GRASS with v.in.ascii. Currently I need to create one GRASS vector file
per variable due to only being able to access a single "GRASSRGB" column
for coloring.

Taking this further, and acknowledging that d.vect is already
overwhelmingly complicated, perhaps a color_rules= option could be
added to access one of the standard GRASS raster color maps (in
$GISBASE/etc/colors/), fit to data, and then use on-the-fly?
e.g. use with LIDAR data where DB holding GRASSRGB column can't
exist and just too huge for d.vect.thematic (if it worked without a data
column).

Even further- allow access to any colr/ file created with r.colors.
But mixing raster/vector functions like this isn't very clean and is to
be avoided...

re. d.vect being way too complicated to quickly use or learn:
An idea would be to keep d.vect powerful but split up the functionalily
in the GUI into "display points" and "display areas" etc. as the "Add
vector layer" panel is already too much for a new user. split up into
features,colors,labels,query sections which can be collapsible? dunno.

I already use scripts for displaying points and areas (d.stations and
d.varea on the wiki add-ons page) as d.vect has too many options to
quickly type. And I see the existance of useful work around scripts to
be a sign there is a problem that should be fixed at the core.


regards,
Hamish