[GRASS5] Problems with vector import, and a suggestion

[Radim Blazek]

On Thursday 07 February 2002 16:37, Michel Wurtz wrote:
> On the other hand, I believe much in postgis, which could be a nice
> "container" for all vector and site stuff in grass, with only an
> import/export function for the actual vector and site format,
> leaving only rasters in flat files. I will be specialy interested
> by what Radim think about that and the possible impact on grass51
> vector format.

I think that in 90% of cases flat files are better because of :
- complicated database administration
- performance
- running postgresql server required (think about PDA 
          or CD-ROM with data+viewer distribution)
- missing topology in PostGIS
(i am not talking about mapservers here where is distinct situation).

For example benchmark in grass51 with flat and postgis (seconds):
Action          native     postGis
import             1                26
display            1                1
export             1                3

And short description of PostGIS instalation:
- get sources for PostGIS 
- compile in postgresql tree
- install, start
- create user
- create new database 
- create PostGIS  functions in database 
   CREATE FUNCTION plpgsql_call_handler() ....
   psql -f /usr/local/pgsql/share/contrib/postgis.sql -d pgis 
- create table with column type "geometry"
Is it acceptable for user who want to digitize just few sites for example?

But in some cases, especially when simultaneous write access is required,
RDBMS is the only solution. 

Due to all mentioned above, I think that  we need both flat files and PostGIS 
and so grass51 is designed now. 
PostGIS support is very weak now but there are people working on that on 
University of Sannio / Benevento. 
There is possibility to test external data formats (shapefile and PostGIS) in 
grass51 for more than one month. Have you tested? What do you think about?

I hope that PostGIS format will not impact on grass too much, because
that would result in abandonment of topological model. Current solution
expects that primitives (boundaries,lines ...) are saved in PostGIS 
and grass native topology model is used for areas.

> Another solution is a "unified" interface for databases : not only for
> postgresql, but also dbf or simple ascii tables (like site files)...

We have DBMI, which is such solution. Are you thinking about anything
else. If so, why?

> Well, I was long, sorry...

Well, I was long, sorry...

Radim