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

[Roger S. Miller]

On Tue, 15 May 2001, Justin Hickey wrote:

> In our case, vector data is used not only in rendering but for analysis
> as well. Thus, the attribute data will be extra work in some cases for
> the analysis programs to deal with. For example, programs that create or
> delete vector data will also have to deal with the associated graphic
> attributes.

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.  I think
it's a substantial advantage if the drawing attributes can be created
and deleted along with the drawn object.

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

There are always differences in opinion.  Software will never be able to
resolve them all. Simultaneous rendering won't be a problem in GRASS until
permissions are changed to allow multiple access to a single mapset.

Both of these problems -- to the extent that they are problems -- are
already dealt with for raster data.

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.

> A solution to these problems is not to store the graphic attributes with
> the vector data. I think this is what Radim was trying to say. Instead,
> the graphic attributes can be determined at rendering time. For example,
> a program could call a renderVect() function that will use current
> settings for the graphic attributes to render the data. 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?

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.

Currently ps.map uses the raster database, vector database and the paint
database, and combines those with additional data provided by the user to
generate an illustration.  The raster data, vector data and the paint data
can be changed, and the changes are reflected (sometimes in a broken
sort of way) in the final product.

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.


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'