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

[Justin Hickey]

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.

"Roger S. Miller" wrote:
> 
> On Tue, 15 May 2001, Justin Hickey wrote:
> Excluding drawing attributes from the data set doesn't solve the
> problem of what to do when vector data are created or deleted.  It
> just moves the problem off to another sector where it has to be
> separately supported and where the user bears the burden of
> maintaining the database.

With state variables, there is basically no maintenance besides choosing
which attributes a user wants and saving them to a file until the user
wants to change them again. All of which is performed through a
convenient interface.

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

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?
 
> 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.
 
> I do see a related problem.  Drawn objects are often used in multiple
> images - base maps, for instance.  If all of the drawing attributes 
> are stored as part of the vector attributes, then every instance of
> the same object will be drawn with the same attribute.  If a user
> want's different attributes for different illustrations then the
> attributes will have to change each time the drawing is rendered.

So which do you feel is easier for the user, editing each vector file or
clicking a button to change the state of the current attribute setting?
What I am thinking of here is a toolbar with buttons to change the
current attributes, similar to Photoshop.

A similar scenario is a map production company that has hundred's of
maps that cover an area. They set the line width for roads to be 1. Then
a client comes along and wants the line width to be 3. With graphic
attributes stored with the vector data, all the maps have to be changed,
and since this is the only client that wants this, they have to be
changed back afterwards. With state variables, the line width is set to
3 before they print roads, then set back again afterwards - two simple
changes.

> > These settings of course can be set by default, or by another
> > program, or even be set from the grassrc file.
> 
> There will always be default drawing attributes.  Currently those
> defaults are hard-coded into GRASS.  Is that really a good thing?

No, and that is not what I suggested. With state variables these
defaults can be stored in a file which the user can change to set
his/her own preferences. Of course, there would be an interface for the
user to change these defaults. We can even let the user create temporary
state variables. That is, variables that the user sets but are not saved
as defaults. This would make the map production example I gave even
simpler since they would only need to set a temporary variable and the
next time they used the system, the line width would be back to 1. So
now we have one change versus hundreds of changes.

> Perhaps the solution is to maintain a set of default drawing 
> attributes inherent in the object and separate tables of drawing
> attributes that are specific for an illustration.  The default
> attributes might be changed by a "preferences" setting and stored in
> an rc file but wouldn't otherwise be manipulated by the user.
> Typically the standard GRASS monitor would use the default
> attributes. Drawing attributes for a specific illustration
> would be initialized from the default set and manipulated with a
> rendering program like ps.map or it's successors.

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.

Interestingly, if you include GRASS monitors in your solution, then you
are implementing state variables with the defaults stored with the data.
However, the user will still have to always change data that does not
match their preferences. And if they can't change the defaults, then
they always will need to change them. You could make this easier for
them by saving their choices. But then what would be the reason for
storing the defaults with the data? Users will override them with their
own preferences, thus, storing them with the data is not necessary. Now
you have the system I have suggested. :-)

> I can think of two ways around the problem.  Either the illustrations 
> can be static and based on copies of the original data -- which
> pretty much destroys the advantage of having the data in a GIS to
> start with -- or it can be dynamic and maintained by the GIS.  In the
> latter case, the database of drawing attributes wouldn't be stored
> with the vector attributes, but it would be "attached" to the
> original vector data (and to the raster data) and updated when the
> original data are changed.
> 
> We don't solve any problems by excluding drawing attributes from the
> vector database.  The data have to be there.  They can either be 
> hardcoded into the programs, or they can be obtained from a database.
> I think that it's far better to include them in the database.

You missed the third option - state variables. :-)

Let's see if I can clarify my argument. The only purpose for graphic
attributes is for presentation. 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?

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.

I hope I have clarified my suggestion, have I?

-- 
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!!!
==================================================================

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