[GRASS-dev] [GRASS-SVN] r71093 - grass/trunk/vector/v.in.ogr

[Markus Metz]

On Wed, May 17, 2017 at 5:23 PM, Moritz Lennert <
mlennert at 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 at gmail.com
>> <mailto:landa.martin at gmail.com>> wrote:
>>> 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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170517/363cf6be/attachment.html>