<div dir="ltr"><div><br><br>On Wed, May 17, 2017 at 9:31 AM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> Hi,<br>><br>> 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.<br>><br>> In short: I would like to plead for v.in.ogr to support exactly the same syntax as ogr.<br>><br>> Example:<br>><br>> ogrinfo "PG:host=myhost user=theuser password=thepassword dbname=thedatabase" theschema.thetable -so<br>><br>> gives me the correct information about a table and<br>><br>> ogr2ogr myshapefile.shp "PG:host=myhost user=theuser password=thepassword dbname=thedatabase" theschema.thetable<br>><br>> gives me a shapefile corresponding to the content of the table.<br>><br>> I would, therefore, expect to just be able to do this:<br>><br>> v.in.ogr "PG:host=myhost user=theuser password=thepassword dbname=thedatabase" layer=theschema.thetable out=mygrassmap<br><br></div>I agree<br><div>><br>> 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.<br>><br>> However, I get the fatal error<br>><br>> "the database 'thedatabase' does not exist".<br>><br>> In order to get my layer, I have to jump through a series of hoops:<br>><br>> db.connect driver=pg database=thedatabase schema=theschema<br>> db.login driver=pg database=thedatabase host=myhost user=theuser password=thepassword<br>> v.in.ogr input="PG:dbname=thedatabase" layer=theschema.thetable out=mygrassmap<br>><br>> Only providing layer=thetable does not seem to work, even though the schema was already defined using db.connect.<br>><br>> Besides being overly complicated (as I said, maybe I missed a simpler way), this actually raises two very serious problems:<br>><br>> - 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.<br>> - 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).<br><br></div><div>It seems that v.in.ogr is confusing input and output, or it is unfinished work for customized PostGIS import not using OGR. I have effectively deactivated the new get_datasource_name() fn in trunk r71093. v.in.ogr should now work again with OGR syntax, and there is no need to change the GRASS db connection settings.<br></div><div><br></div><div>Markus M<br><br></div><div>><br>> 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.<br>><br>> And I think we should not move away from ogr in v.in.ogr.<br>><br>> 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.<br>><br>> 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).<br>><br>> 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 ?<br>><br>> Please let me know if I just completely misunderstand the functioning of v.in.ogr for PostGIS layers at this stage...<br>><br>> Moritz<br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br><br></div></div>