[GRASS-dev] PostGIS layer import

[Moritz Lennert]

Hi,

I know there have been discussions on this before, but I would like to 
come back to the question of how to handle imports of layers from 
PostGIS databases. Possibly there are some elements I still don't really 
understand, so I'm launching this debate here, instead of as a bug report.

In short: I would like to plead for v.in.ogr to support exactly the same 
syntax as ogr.

Example:

ogrinfo "PG:host=myhost user=theuser password=thepassword 
dbname=thedatabase" theschema.thetable -so

gives me the correct information about a table and

ogr2ogr myshapefile.shp "PG:host=myhost user=theuser 
password=thepassword dbname=thedatabase" theschema.thetable

gives me a shapefile corresponding to the content of the table.

I would, therefore, expect to just be able to do this:

v.in.ogr "PG:host=myhost user=theuser password=thepassword 
dbname=thedatabase" layer=theschema.thetable out=mygrassmap

In GRASS 7.0 this works. According to the trunk man page, this should 
also work (unless the example given (v.in.ogr input="PG:host=localhost 
dbname=postgis user=postgres" layer=polymap output=polygons 
type=boundary,centroid) is only valid for localhost connections.

However, I get the fatal error

"the database 'thedatabase' does not exist".

In order to get my layer, I have to jump through a series of hoops:

db.connect driver=pg database=thedatabase schema=theschema
db.login driver=pg database=thedatabase host=myhost user=theuser 
password=thepassword
v.in.ogr input="PG:dbname=thedatabase" layer=theschema.thetable 
out=mygrassmap

Only providing layer=thetable does not seem to work, even though the 
schema was already defined using db.connect.

Besides being overly complicated (as I said, maybe I missed a simpler 
way), this actually raises two very serious problems:

- As I changed the db.connect settings to read a database, all future 
writing of attributes will now happen using these settings, which is not 
at all what I want.
- If theuser only has 'select', but not 'create table' rights in the 
database and schema, then the v.in.ogr call fails because it cannot 
write the table (since it tries to write it to the PostGIS database 
because of the db.connect settings).

I understand that there are many different situations in databases and 
that it is difficult to handle them all, but (again: unless I'm 
completely misunderstanding things) the current handling just seems not 
only overly complicated, but actually with serious consequences and errors.

And I think we should not move away from ogr in v.in.ogr.

In addition, in the GUI import wizard, after having set db.login and 
being able to see the available tables with 'v.in.ogr -l', the GUI 
cannot list these same tables because it seems to attempt to connect to 
the database 'template1' to which the defined user does not have access 
rights.

Finally, db.login does not allow erasing existing settings, but the GUI 
takes its information from the login file when determining where to 
connect when "database" is chosen in the import wizard. One has to 
manually erase the file (or relevant lines in the file).

Maybe a v.in.postgis handling special access needs might be a solution, 
leaving v.in.ogr as a real frontend to ogr with exact same behaviour as 
ogr ?

Please let me know if I just completely misunderstand the functioning of 
v.in.ogr for PostGIS layers at this stage...

Moritz