[GRASS5] Multiple attribute support in GRASS 5.1: someconsiderations (long)

David D Gray ddgray at armadce.demon.co.uk
Sun May 13 15:43:13 EDT 2001


"Roger S. Miller" wrote:
> 
> aaime wrote:
> 
> > During the last days I've spent some time thinking about new vector
> > capabilities in GRASS 5.1, and in particular for what concerns multiple
> > attribute support and DBMS integration..
> 
> I think it would be desirable if that data-base support also associates
> drawing attributes with the vector objects; e.g. area color fill and
> pattern, line weights, line styles, line color, point symbol, size and
> color.  No doubt there are more.  Presentation is one of the most
> important functions of GIS.  GRASS' current state of division between
> analysis and presentation will make further improvements difficult.
> 

Roger

Though this is broadly to be welcomed, a number of alarm bells are
ringing here. One of the problems with entry-level GIS, which echoes a
problem across the whole spectrum of desktop philosophy and culture, is
the problem of over-integration of logically distinct functions.
Presentation is very important, and no-one will deny GRASS has much
(everything!) to still do here, but it _is_ something essentially
different from analysis, and digitising - which is really a CAD-like
function - is something different again, tho' the latter is related to
data structure and storage. I include such functions as cut and patch as
`digitising'. Analysis needs to deal with attributes and it needs to be
spatially aware, but doesn't mostly need to edit - if need be it can
call the editing layer.

It is good to keep the processes the user doesn't need (or want) to see
in the background, but it is also important to make sure the engine
processes each stage the best way, logically, it can and not compromise
the whole by confounding the parts. It's always _easier_ to cut corners
but I think we can achieve what you suggest as long as we keep in mind
what we are aiming for is to maintain GRASS as a `high-end' system.

> Regarding the separation of vector data and site data...
> 
> Sites should function as a tie between a map location and a database.
> The current support for sites is a conceptual start in that direction,
> but of little practical use.  For instance, one of my clients has
> somewhere over a 100 sites (wells) with a few to 100's of pages of data
> that is uniquely associated with each site.  That is by no means a large
> example.  I would like to be able to use a site list-like feature to
> organize and access that data.
> 
> If your concept of data base support for vectors can be extended that
> far, then by all means merge site lists with vectors.  It will make
> things much simpler. Otherwise, I think it is far better to keep sites
> for separate development.
> 

In the version 5.1 dig file, there are now separate entity types for
point data. There is a `site' record and a `centroid' record, which are
both point types. Actually both are new: the old way of registering a
point is as a line of two identical points, and the location of the
degenerate nodes is the site location. Area point features are stored
currently in dig_att. In GRASS 5.0 however mostly sites use the
text-based sites API.

This suggests moving on to the possibility of linking up to heavy duty
RDBMS engines where more than a few small attributes or complex linking
is required. So plugins to PostgreSQL/Oracle/etc. or ODBC need to be
developed to handle this. But surely this is overkill for the attribute
data requirements of most maps, so for day-to-day needs, a simple
vanilla DBMS system should do.

The sites API will probably go the way of many redundant features in
GRASS. It will be dropped when the vector engine takes over its
functions.

David

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



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



More information about the grass-dev mailing list