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

[John Reid]

Hi all,

"Eric G. Miller" wrote:

> On Sun, May 13, 2001 at 11:06:58PM -0600, Roger S. Miller wrote:
> [snip]
> > My concern is that *if* there is any intent to improve the presentation
> > capabilities available in GRASS then it will ultimately be necessary to
> > provide database capabilities to serve drawing attributes.  Those
> > capabilities can be built as an inherent part of the vector attributes
> > database.  Alternatively the database capabilties can be added later in
> > a separate, parallel and mostly duplicative effort.  The latter
> > alternative makes little sense to me.
> >
> > I think there's a substantial need in GRASS for integration of map
> > preparation, map analysis and map presentation.  Certainly it would be
> > possible to go too far in that direction, but right now we are so far
> > from that extreme that worrying about it seems a little premature.  If
> > my own setting is an indicator then public use of GRASS will be limited
> > until the time that GRASS offers more evenly balanced and integrated
> > capabilities.
> [snip]
> > I think David is right that it would be overkill for day-to-day needs,
> > so long as those needs are limited to the needs for map analysis, and
> > probably for map presentation.  The data needs for map construction are
> > much greater than the needs for analysis or presentation and a database
> > system designed to give the capabilites needed for map analysis is
> > likely to be woefully inadequate to serve the demands of map
> > construction.
> >
> > GRASS currently offers some Postgres support, and certainly that is
> > helpful for map construction, but it doesn't come close to meeting the
> > needs.
>
> I think we all can agree GRASS has a ways to go on both attribute data
> support *and* presentation.  Now, if for a vector "map", if each
> layer/component (SITE, LABEL, LINE, AREA) has a separate attribute table
> then wouldn't it be a simple matter to *allow* the user to define one
> column of the table to indicate a "style" for the given thing.  Then
> presentation routines could be told which field to use for looking up
> the drawing style for the given thing.  The styles themselves, could
> consist of simple text files defining some appropriate variables.  GRASS
> would provide a "DEFAULT" style as well as several "sample" styles.
> Styles could be indexed by name or number and would reside outside of
> the database proper (e.g. in etc/styles/ and possibly
> /home/user/.grass5/styles/).
>
> Hypothetical polygon style example:
>
> [myStyle]
>
> AREA {
>         line-color: #000000;
>         line-width: 0.4pt;
>         fill-style: stipple;
>         fill-pattern: hatchure10;
>         fill-foreground: #0000FF;
>         fill-background: transparent;
> };
>
> The details would have to be fleshed out.  If a style could not be
> rendered or found, the drawing agent should try to render what it can
> (possibly using the default settings).
>
> Being able to define display styles that aren't tied to a particular map
> makes it easier to apply them to subset maps or related maps and get
> consistent results while only having to define the style once.  Also, I
> think such a thing doesn't unduly burden any analysis/management aspects
> of the system.
>
> Comments?

Has anyone had a look at the draft ISO standards?  They deal with a lot of these
issues.  Been talking to our local rep on the TC/211 geomatics committee, and the
impression I get is that they are not averse to open source apps implementing the
standards ;-)  More on this if anyone interested.

> --
> Eric G. Miller <egm2 at jps.net>

cheers,
John
--
----------------------------------------------------------------------
john reid                                  e-mail john_reid at uow.edu.au
technical officer                                room G02, building 41
school of geosciences                           phone +61 02 4221 3963
university of wollongong                          fax +61 02 4221 4250

uproot your questions from their ground and the dangling roots will be
seen.  more questions!
                                                       -mentat zensufi

apply standard disclaimers as desired...
----------------------------------------------------------------------



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