[GRASS5] Named attribute support in GRASS

[Carl Worth]

 > I'm considering writing a vector line module similar to d.vect.area, only
 > it'd be for drawing labelled lines in different colors via a similar
 > legend file (yea? nay? don't care?).

Eric,

Thanks for this excellent work.

I've been thinking, and it seems like a better long-term solution is
to move away from a new "legend file" and make better use of
attributes in GRASS.

I've been looking at the sites format, (I don't know how other formats
compare), and it does allow for named attribute columns, but the names
are rarely used in GRASS. Instead, the attributes are referenced by
index, (oddly, by an index specific to each attribute type).

It seems like it would be quite nice if, instead of doing something
like:

	d.site.labels index=2

I could do:

	d.site.labels label=name

where "name" is the column name for a string attribute.

Similar features would be quite nice for colors, symbol types, and
line styles, (once they are supported). It could also be quite
convenient if modules would take default values from attributes of the
correct name, (ie. standard attribute names such as "color" and
"symbol" could be established and would be examined by default).

Perhaps it would make sense to invent some syntax for specifying an
attribute name on the command-line that would prevent a clash with
string literals, such that, perhaps:

	d.site.labels label=name

would display the string "name" at each site, whereas:

	d.site.labels label=<name>

would display the value of the attribute named "name" at each site.

Of course, for completeness, there would also be a means to escape
whatever delimiter was used. An alternate option would be to make
separate arguments for accepting literals vs. attribute names,
(eg. label=literal vs. label_attr=attr_name). But in my opinion that
is more awkward.

With better named attribute support, we would be closer to being able
to integrate GRASS with a database system, (such as PostGIS for
example). Of course, this would require carefully modularizing GRASS
such that all data-access functions were collected into a single
library, (which is an important thing to do for maintenance sake
regardless).

-Carl