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

[Roger S. Miller]

Justin Hickey wrote:
> 
> Hi Roger
> 
> It seems you did not understand my suggestion, which is to use state
> variables to handle graphic attributes. Perhaps I wasn't clear enough.
> More on this as we go along.

Actually, I think we may agree on the use of "state variables."  I used
a different terminology.
 
> > > Another problem with storing the graphic attributes with the
> > > vector data is when vector data is shared. If user A wants a vector
> > > file to display lines as dashed lines and user B wants them
> > > displayed as solid lines, how is this case handled, especially when
> > > they both try to render them at the same time?
> >
> > Simultaneous rendering won't be a problem in GRASS until
> > permissions are changed to allow multiple access to a single mapset.
> 
> Just because a problem doesn't exist now, doesn't mean it won't exist in
> the future. We need to plan our work with all foreseeable problems we
> can determine taken into account. Correct me if I'm wrong, but hasn't it
> been suggested (and maybe it's in the TODO list) that the permission
> policy of GRASS should be changed? In fact, you did some work in this
> area before. Thus, I think we can't ignore the situation I describe
> above since it seems likely that it could occur at some point in the
> future. So again, how would your design handle this case?

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.  For that case we need a separate set of drawing attributes
for each illustration.  Furthermore, if the illustration is to remain
dynamic (changing when the underlying vector data are changed) then
those sets of drawing attributes must be maintained as an optional part
of the vector attributes database.  That means (for instance) that if a
vector object is deleted from the database, then it's drawing attributes
need to be removed from the set of attributes used by any illustration
that uses the object.

Perhaps that requirement is too stringent for GRASS.

> 
> 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.

> > Both of these problems -- to the extent that they are problems -- are
> > already dealt with for raster data.
> 
> I'm sorry, but could you please elaborate? I don't see how this is
> related to our discussion. Perhaps due to my ignorance of how raster
> graphic attributes are implemented in GRASS.

Mulitple access problems aren't unique to the vector drawing
attributes.  I think that needs to be addressed in a different thread.

GRASS already supports the use of different drawing attributes for
raster maps.  For instance, we have reclass maps, regions, 3dviews and
color tables that are supported and maintained by the system and are
quickly manipulated to prepare different images.  If a raster file is
removed, then the database elements associated with it are also removed.

That support is perhaps not as developed as it could be.  I would like
to see at least that much support provided for vector drawing
attributes.
  
> Why should the GRASS monitor only use defaults? Users should be able to
> set whatever attributes they want for any device that renders a vector
> map, including the GRASS monitors.

I agree, but remember there are several respondents that didn't want to
support drawing attributes at all.  I was simply allowing the system to
operate with default attributes for those people who don't want anything
else.
 
> 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.  Nothing is drawn without attributes; you can't
draw a line even on the most basic of monitors without a line width, a
line style and a line color.  You can't draw a point without a size, a
color and a style.  There is also no clear distinction between
attributes needed for vector analysis and attributes needed for
presentation, though clearly one would want to manipulate more
attributes for illustration than for analysis.

> The next question is "Who decides what
> the attributes should be for presentation?". The answer in my opinion is
> the users. They are the ones that want to see the map in a particular
> way. Thus, we should let them do what they want but keep them from
> interfering with other users of the same data that have different
> preferences. And at the same time, we provide them with a simple
> interface to manipulate the attributes. Do you agree that this is a
> desirable goal?

I agree completely, but don't forget that somewhere in the morasse of
code there are inherent defaults.  Currently, lines are displayed in
white, as solid lines with a single-bit width.  Points have a similar
set of defaults.

> State variables can achieve this goal since each user has their own set
> of variables. I can't see how this goal can be achieved if we store the
> graphic attributes with the vector data, since the attributes are not
> associated with the user in any way. If a user wants different
> attributes, he has to change the data which effects any other user that
> wants to use this data afterwards.

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.


Roger Miller
Lee Wilson and Associates

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