Hi,
2017-05-17 15:00 GMT+02:00 <svn_grass@osgeo.org>:
+ /* TODO: remove below code, or use it in e.g. a new v.in.pg */
-1
v.in.ogr should work for all datasources. Special care should be done
for database sources. Connection string can be provided as fully
qualified. But also stored connections (via db.login) should be also
taken into account. Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Wed, May 17, 2017 at 3:09 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2017-05-17 15:00 GMT+02:00 <svn_grass@osgeo.org>:
- /* TODO: remove below code, or use it in e.g. a new v.in.pg */
-1
v.in.ogr should work for all datasources. Special care should be done
for database sources. Connection string can be provided as fully
qualified. But also stored connections (via db.login) should be also
taken into account. Martin
db.login is used for database access where GRASS reads/writes attribute tables, right?
Why should these settings be used for OGR input? With v.in.ogr, OGR input can be anything, and OGR input has nothing to do with where GRASS creates a new attribute table. It is not clear why OGR should take into account GRASS db settings. Obviously this only causes confusion.
Markus M
On 17/05/17 15:18, Markus Metz wrote:
On Wed, May 17, 2017 at 3:09 PM, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:Hi,
2017-05-17 15:00 GMT+02:00 <svn_grass@osgeo.org
<mailto:svn_grass@osgeo.org>>:
> + /* TODO: remove below code, or use it in e.g. a new v.in.pg
<http://v.in.pg> */
-1
v.in.ogr should work for all datasources. Special care should be done
for database sources.
It does, in the version that Markus committed. It did not work for me in the previous version.
Connection string can be provided as fully
qualified. But also stored connections (via db.login) should be also
taken into account. Martin
That is something else, i.e. do we want to create more convenience.
db.login is used for database access where GRASS reads/writes attribute
tables, right?Why should these settings be used for OGR input? With v.in.ogr, OGR
input can be anything, and OGR input has nothing to do with where GRASS
creates a new attribute table. It is not clear why OGR should take into
account GRASS db settings. Obviously this only causes confusion.
I agree with Markus here. db.connect/db.login settings should IMHO not be (ab)used for read access to DBs.
I would, therefore, plead for a separate approach as already mentioned (either db specific as in v.in.postgis, or generic in a v.in.db (I know this name is already taken by an existing module with different functionality) which might make it easier to define database connections and possible allow the storage of connection parameters.
Currently, selecting "Database" in the import wizard also only works for database that are on localhost. It would be great if information such as host, database, login, and password could be passed to the wizard. Maybe a specific v.in.db type module could help with that ?
Moritz
On Wed, May 17, 2017 at 5:23 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 17/05/17 15:18, Markus Metz wrote:
On Wed, May 17, 2017 at 3:09 PM, Martin Landa <landa.martin@gmail.com
mailto:[landa.martin@gmail.com](mailto:landa.martin@gmail.com)> wrote:Connection string can be provided as fully
qualified. But also stored connections (via db.login) should be also
taken into account. MartinThat is something else, i.e. do we want to create more convenience.
Stored connections should only be taken into account if the current GRASS database connection uses PostgreSQL. The default is SQLite3. A corresponding test appears too late, the damage is already done.
Stored GRASS connection settings could only be used if some OGR PostGIS settings are missing. Instead, the current implementation 1) changes user-supplied parameters, 2) discards user-supplied parameters.
I have fixed relbr72 in r71096.
Markus M
db.login is used for database access where GRASS reads/writes attribute
tables, right?Why should these settings be used for OGR input? With v.in.ogr, OGR
input can be anything, and OGR input has nothing to do with where GRASS
creates a new attribute table. It is not clear why OGR should take into
account GRASS db settings. Obviously this only causes confusion.I agree with Markus here. db.connect/db.login settings should IMHO not be (ab)used for read access to DBs.
I would, therefore, plead for a separate approach as already mentioned (either db specific as in v.in.postgis, or generic in a v.in.db (I know this name is already taken by an existing module with different functionality) which might make it easier to define database connections and possible allow the storage of connection parameters.
Currently, selecting “Database” in the import wizard also only works for database that are on localhost. It would be great if information such as host, database, login, and password could be passed to the wizard. Maybe a specific v.in.db type module could help with that ?
Moritz