[GRASS5] Postgresql and Grass

Eric G . Miller egm2 at jps.net
Sun Sep 17 12:26:45 EDT 2000


On Sat, Sep 16, 2000 at 05:52:22PM +0200, Andreas Lange wrote:
> Hi,
> 
> i can only jump into this discussion now and i must admit that i have
> very little experience with database/gis interoperability.
> 
> In my eyes the most needed things are:
> - color support for vectors (please use the structure from raster maps
> so that users do not have to learn another system)

I'll add hatchure patterns and more line/marker styles (mostly for
ps.map ...).

> - full category/attribute support for vectors, 
> - selection and reclassification of vectors based on attributes.

Yes, I like to see something similar to Arc/Info's RESELECT.  The d.*.pg
commands kind of do this, but something with a little more persistence
might be in order.

> (- maybe inclusion of vectors in the raster based MASK selection in
> GRASS?)
> - metadata/history support for vectors. 
> 
> I personally would prefer GRASS not to be tied to a specific database
> server (PostgreSQL or any other). The Unix-ODBC is great, but limits the
> connectivity to relational DBMS (?). I got the impression that the
> object-oriented DBMS are not yet ready for wider use and wonder if there
> is an open implementation for a object-oriented DBMS. 

Agree with (1), not sure about (2).  Although it may be heresy to
suggest, there are at least a couple implementations for using "legacy"
Xbase type files.  Including indices...

> The flat-file approach of GRASS has many advantages for small datasets
> and i think it should be possible to have both (flat-file database and
> connection to DBMS) within GRASS. 
> 
> GRASS vectors IMHO should be usable without a DBMS (with reduced
> functionality). 

I don't see why there needs to be "reduced functionality".  Well, maybe
no concurrent writers!

> I think that the main problem is that there are until now no widely
> accepted, open data structures/formats for both data and metadata. Many
> solutions are proprietary or only used by specific communities within
> GIS.

Yep, everyone's rolled there own (including GRASS).  Even the various
agencies with the U.S. Federal gov't have promulgated at least half a
dozen different vector file formats (not to mention rasters).  However,
FGDC metadata is becoming quite common (and widely supported).  I
believe there's a proposed ISO standard that's very similar (need to
check... confused with SDTS??).

> XML seems to be an alternative, but i have no idea if it is possible to
> use XML for data storage (speed considerations, indexing etc.) or if it
> is only useful for data exchange.  

I'm skeptical about XML for day-to-day.  Seems to incur alot of parsing
overhead.  Good for data exchange though.

> I hope that the experts can give a draft on the alternatives so that
> users without much background in computer science and database design
> can comment on this.

Well, I'm no expert but I've got at least a vague idea of a directory
hierarchy for attribute tables in GRASS:

                 [mapset]
                     |
                   [tbl]
                     |
        ------------------------------------------------
        |                 |                            |
     [free]            [vector]                      [cell]
        |                  |                            |
        |---table1       [map]                        [map]
        |                  |                            |
        |---table2         |                           cat
        |                  |---area
        ...                |---line
                           |---site(?)
                           |---node(?)
                           |---network(?)
                           |---route(?)
            
Generally, the idea is, there's a 'tbl' directory.  Under the table
directory there are three directories 'free', 'vector' and 'cell'.
'free' would refer to any extra table not bound to a spatial layer
through a cat #.  Under both 'vector' and 'cell' would be a directory
for each raster or vector map.  Only integer cells are considered, maybe
all types?  Under vector, there'd be files for line attributes and area
attributes keyed on cat#.  I don't know about sites or labels or
possible additions to the current vector model.  At the top level
directory 'tbl' some kind of file listing 'tied' tables and their join
key(s) could be listed (so things like the USDA SSURGO database could be
accomodated).

This'd all take a bit more consideration... Definitely a post GRASS 5.0
stable thing.

-- 
/bin/sh ~/.signature:
Command not found

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