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

[Michael Barton]

Just a quick note.

I'm about to release for testing a fundamentally rewritten GIS Manager II.
This does not yet address the issues that Hamish raises below, but hopefully
begins to provide a platform for doing so.

I hope to get this onto my website and into the CVS today or tomorrow. If
someone out there could produce a GRASS GUI WIKI page, I could put this and
the UI design documents there also.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Mon, 16 Jan 2006 17:18:32 +1300
> To: <grass5 at grass.itc.it>
> Cc: Martin Landa <landa.martin at gmail.com>
> Subject: Re: [GRASS5] d.vect -a|c for all types ver2
> 
> 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
>