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

[Justin Hickey]

Hello all

"Roger S. Miller" wrote:
> 
> Radim Blazek wrote:
> 
> > I think that symbology of geographic data is usualy based on 
> > attributes and dynamicaly created. Assigning color, style, width to
> > graphic elements is good for CAD systems not for GIS. We work on
> > data not on pictures.
> 
> My clients pay for a product.  That is pretty true for anyone working 
> in the private sector.  Analysis is necessary, but if I can't turn
> out a product then I don't have a job.  What's more, if I have to use
> some other tool to produce the final product, then I may as well use
> some other tool to perform the analysis.
> 
> I've been studying GIS for about 15 years.  Aside from a few publicly
> supported projects like GRASS, every GIS I know of places 
> considerable emphasis on presentation.

I've been lurking with this thread mainly because I am not a GIS person
and cannot add much in terms of vector analysis and efficient use of
vectors. However, I hope you will let me throw in my 2 cents here from a
computer science and graphics point of view.

Correct me if I misinterpreted things, but I think the question here is
where should the graphic attributes (style, width, color, etc.) be
stored for vectors? In most computer graphics texts, they recommend that
the graphic attributes be stored with the graphic objects. Thus whenever
the object is rendered, the attributes are there for the rendering
engine. This, I think, is basically the reasoning behind those that want
to store the graphic attributes with the vectors. However, in this
graphics theory, the graphic objects are not used for anything but
rendering.

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

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. This way, the graphic attributes are defined by
the user, not the data. Also, the renderVect() function would be generic
so that all programs (like d.vect or ps.map) would call it passing down
the data and the device to use. Thus, device dependent code is only
located in one function. In fact it would be nice to have a single
"render vector map" program that would render any vector map to any
supported device using options and/or environment variables to select
the graphic attributes and device. I don't know if this is doable, just
a thought.

So, if I understand Radim correctly, then I would have to agree with him
that the graphic attributes should not be stored with the vector data in
our case. They should be determined at render time instead.

Thanks for reading.

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