[GRASS5] Multiple attribute support in GRASS5.1:someconsiderations(long)

[Justin Hickey]

Hi Roger

"Roger S. Miller" wrote:
> The use of state variables would help with multi-user preference
> problems, but it does little to help with the needs of users who must
> prepare several illustrations based all or in part on a single set of
> vector data.

Or even worse, where there are several data files to be used for the
presentation but with different attributes for each file. The attributes
would need to be changed before each file was rendered. Now I see where
your proposal is necessary. See below for more.

> > Even if the above situation never occurs, people sharing the same
> > data file and wanting different graphic attributes will have to
> > change the attributes frequently. Person A sets his attributes,
> > then person B sets hers, then person A comes back and has to set
> > his attributes again. Do you agree that this situation is not very
> > user friendly?
>
> If each person has there own set of state variables, then this
> problem will only arise if two or more people are working on one
> illustration. In fact, there isn't any software anywhere - and never
> will be - that can settle a disagreement between two people working
> on one illustration.  That's what supervisors are for.

Hmm. This and your statement below indicate we are using different
definitions for presentation/illustration. I am taking the general
definition that any rendering of the vector data is a presentation. This
includes graphics monitors, postscript files, printers, images, etc.
Whereas you seem to be excluding graphic monitors. Therefore, the
situation I described above can happen. In fact, in my office I have
seen people use d.vect to render the same data using different colors.
Thus, the use of state variables here is beneficial.

In general I think we need to look at this problem including all forms
of rendering, not just hardcopy.

> > Let's see if I can clarify my argument. The only purpose for 
> > graphic attributes is for presentation.
> 
> That isn't quite true.  Drawing attributes are used every time a 
> vector object is displayed.

As I indicated above, I include all types of rendering in my definition
of presentation. That's why I call it presentation and not illustration
since even graphic monitors present the data to the user.

> The global default attributes would be stored in the system.  User
> preferences (alterations of the defaults) could be stored in the 
> user's space.  The tables of attributes prepared by the user for each
> illustration can be kept as separate tables within the vector 
> database, much as 3dviews are stored now for raster illustrations.
> 
> > I hope I have clarified my suggestion, have I?
> 
> I think we agree on the use of state variables.

I think you are right, we actually do agree. So let me see if I get this
right.

Default attributes are stored with the vector data so that they are
available for those who don't care about attributes, or in cases where
specific attributes are desired for particular data. However, we allow
for the use of user defined state variables that would override the
defaults.

I was thinking we could just use default state variable settings for the
default case, but this would not help the situation I described above
(different files with different attributes). Now I'm clear on that.
Sorry for the confusion.

Now that my confusion is cleared up, I'll step out of this discussion
and leave it for the vector guys. :-) Do you other vector people agree
with us?

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================