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

[Roger S. Miller]

David D Gray wrote:

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

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

I appreciate that goal, but as it is now GRASS seems to be intended more
as a `back-end' system, than as a `high-end' system.
 
> > Regarding the separation of vector data and site data...

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

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.


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'