Rich Shepard wrote:
On Thu, 16 Dec 1999, Michel Wurtz - ENGEES/CEREG wrote:
> Besides, I think the real problem with Grass vector format is the lack of
> a good database interface for storing and managing attributes data.That's the problem for raster data, too. For example, cells could have
attributes for soil, depth-to-bedrock, slope, vegetation, aspect,
erodability, and so on. In my opinion, a GIS cannot do meaningful analyses
or modeling without a solid, relational database in which to store
attributes. Mapping, yes; spatial analyses/modeling, no.
Yes, but i think raster data are mainly used for layers containing only
one continuous variable (elevation, sol moisture, slope, etc...), therefore
the database link is not really necessary. It's only for discretes values
(vegetation, soil, administrative entities, ...), which are mainly vector
layers, that connecting to a DBMS is usefull. I know that this is a very
simplified vue, but it should cover 80 to 90% of usages. Neverless, that
is precisely why the raster/vector possibilities of Grass are so interesting,
and why I think that the vector modules should be improved, as they are
-- with the cartographic output -- the weakest point in Grass.
[...]
Let me go out on a limb, here: PostgreSQL. It has native, graphic data
types (and the 8K per tuple limit will be greatly increased in version 7),
had a working interface to GRASS in earler versions of both, and has a team
in Italy working on upgrading that interface.Without provoking a flame war on which dbms is "best", I am strongly
supportive of "officially" supporting postgres. There are a number of
I have also the feeling that postgres is the best choice. This is why
I am actually looking at it far more than at the other DBMS. But I'm
afraid that dealing with Grass _and_ Postgres will
--
Michel Wurtz ENGEES - CEREG
1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97