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