Import PostGIS data into GRASS via QGIS toolbox

[dassau]

I tried to import PostGIS data into GRASS with the toolbox command v.in.ogr. I get an error "Layer not available" in the toolbox with the used command:

v.in.ogr 'dsn=PG:dbname=test host=localhost port=5432 user=dassau' layer=public.roads output=roads -o

the problem seems to be that if you use v.in.ogr from QGIS it takes the layer name together with the name of the schema and so the "wrong" layer definition in the command line looks like this:

layer=public.roads

which is not the way to use it with v.in.ogr. Here I only need the layer name without schema:

layer=roads

thanks a lot

Otto

[jef]

fixed in r7699

[horst.duester]

The r7699 solution doesn't seems to be a good direction. In principle v.in.ogr supports postgres schemas and QGIS should always use qualified table names.

In r7699 QGIS uses mOgrLayers[current]. This is the layer name in the QGIS TOC loaded via Postgres Connection and not the name of the connected schema qualified table. As the result you get the error message "Layer not found"

I'm a little bit confused due to the change of content of mOgrLayers[current]. r7667 has the full qualified table name. In r7699 mOgrLayers[current] contains only the table name.

[jef]

Replying to horst.duester:

The r7699 solution doesn't seems to be a good direction. In principle v.in.ogr supports postgres schemas and QGIS should always use qualified table names.

Which breaks things for Otto. The compile time checks to figure out if grass/ogr actually supports schemas obviously aren't enough. For now the unqualified tablename is used, which should work everywhere unless we actually need the schema name - which I for one consider consider an edge case. We need a better test.

In r7699 QGIS uses mOgrLayers[current]. This is the layer name in the QGIS TOC loaded via Postgres Connection and not the name of the connected schema qualified table. As the result you get the error message "Layer not found"

No, it's the name of the table just without the schema.

[horst.duester]

I don't get it work! All loaded layer are named without schema. I'm not able to load a layer from different schema than public.

My system: GDAL-1.4.2 GRASS-6.2.3

[dassau]

Replying to horst.duester:

I don't get it work! All loaded layer are named without schema. I'm not able to load a layer from different schema than public.

My system: GDAL-1.4.2 GRASS-6.2.3

I worked and tested with public schema and it works, now that layers are named without schema. I haven't tested with other schemas - but that's the problem I guess.

Layers named without schema, can only be load data for schema public and layers named with schema can be loaded for schemas different from schema public.

Maybe, it could fixed with an if-statement. If schema is public use layername without schema else with schema?

[jef]

Replying to dassau:

I worked and tested with public schema and it works, now that layers are named without schema. I haven't tested with other schemas - but that's the problem I guess.

The code makes a distinction between GDAL >=1.4 and earlier versions. With some <1.4 the schema is removed and a warning is put out.

Which version of GDAL and GRASS are you running? Looks like your running a GDAL >=1.4 and your v.in.ogr still doesn't support schemas.

IIRC my GDAL is 1.4.3 and v.in.ogr has the same problem (I'll verify this tonight). I guess the GRASS version should also put into consideration.

[dassau]

Replying to jef:

Replying to dassau:

I worked and tested with public schema and it works, now that layers are named without schema. I haven't tested with other schemas - but that's the problem I guess.

The code makes a distinction between GDAL >=1.4 and earlier versions. With some <1.4 the schema is removed and a warning is put out.

Which version of GDAL and GRASS are you running? Looks like your running a GDAL >=1.4 and your v.in.ogr still doesn't support schemas.

IIRC my GDAL is 1.4.3 and v.in.ogr has the same problem (I'll verify this tonight). I guess the GRASS version should also put into consideration.

I work on debian testing and use GRASS 6.3~cvs20071023 from: deb ​http://debian.gfoss.it/ lenny main. GDAL comes from an official debian repository: gdal-bin 1.4.2-1 and libgdal1-grass -> 1.4.1-1

[jef]

workaround in r7710.

GDAL prepends the schema only to tables that are not in the current schema.

The current schema defaults to the username, if such a schema exists or public otherwise. We would need to introduce a postgres dependency in the grass plugin to figure out the current schema. I'm not sure if that's the right thing to do.

The workaround simply removes the schema from the user's and public tables. This makes public tables accessible, unless a user schema exists. If it does public tables will still be inaccessible.

[jef]

r7711 solves the schema problem in the postgres provider and removes the workaround.

[(none)]

Milestone Version 0.9.1 deleted