[GRASS5] Multiple attribute support in GRASS 5.1:someconsiderations (long)

[Eric G. Miller]

On Sun, May 13, 2001 at 11:06:58PM -0600, Roger S. Miller wrote:
[snip]
> My concern is that *if* there is any intent to improve the presentation
> capabilities available in GRASS then it will ultimately be necessary to
> provide database capabilities to serve drawing attributes.  Those
> capabilities can be built as an inherent part of the vector attributes
> database.  Alternatively the database capabilties can be added later in
> a separate, parallel and mostly duplicative effort.  The latter
> alternative makes little sense to me.
> 
> I think there's a substantial need in GRASS for integration of map
> preparation, map analysis and map presentation.  Certainly it would be
> possible to go too far in that direction, but right now we are so far
> from that extreme that worrying about it seems a little premature.  If
> my own setting is an indicator then public use of GRASS will be limited
> until the time that GRASS offers more evenly balanced and integrated
> capabilities.
[snip]
> I think David is right that it would be overkill for day-to-day needs,
> so long as those needs are limited to the needs for map analysis, and
> probably for map presentation.  The data needs for map construction are
> much greater than the needs for analysis or presentation and a database
> system designed to give the capabilites needed for map analysis is
> likely to be woefully inadequate to serve the demands of map
> construction.
> 
> GRASS currently offers some Postgres support, and certainly that is
> helpful for map construction, but it doesn't come close to meeting the
> needs.

I think we all can agree GRASS has a ways to go on both attribute data
support *and* presentation.  Now, if for a vector "map", if each
layer/component (SITE, LABEL, LINE, AREA) has a separate attribute table
then wouldn't it be a simple matter to *allow* the user to define one
column of the table to indicate a "style" for the given thing.  Then
presentation routines could be told which field to use for looking up
the drawing style for the given thing.  The styles themselves, could
consist of simple text files defining some appropriate variables.  GRASS
would provide a "DEFAULT" style as well as several "sample" styles.
Styles could be indexed by name or number and would reside outside of
the database proper (e.g. in etc/styles/ and possibly 
/home/user/.grass5/styles/).

Hypothetical polygon style example:

[myStyle]

AREA {
	line-color: #000000;
	line-width: 0.4pt;
	fill-style: stipple;
	fill-pattern: hatchure10;
	fill-foreground: #0000FF;
	fill-background: transparent;
};

The details would have to be fleshed out.  If a style could not be
rendered or found, the drawing agent should try to render what it can
(possibly using the default settings).

Being able to define display styles that aren't tied to a particular map
makes it easier to apply them to subset maps or related maps and get
consistent results while only having to define the style once.  Also, I
think such a thing doesn't unduly burden any analysis/management aspects
of the system.

Comments?

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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'