[R-sig-Geo] Error in readOGR / ogrInfo

[Lee Hachadoorian]

Ben,

schema=<schema> cannot be used in a Postgres DSN. Apparently (I haven't
tried it) you can use ConnSettings in the Postgres ODBC driver to pass
in a number of different settings otherwise unsupported, but
ConnSettings doesn't seem to be supported in rgdal.

But jumping through hoops to get that to work probably isn't the way to
go. Just use the schema qualified table name. If you would prefer to
have your table seaplus_countries in schema gms, you just need to do

readOGR("PG:dbname=gms user=benmadin password=xdi4frt",
"gms.seaplus_countries")

Note that you would run into a similar problem with straight SQL. If
seaplus_countries moved to schema gms,

SELECT * FROM seaplus_countries;

would not work either. (But you probably know that.)

With a little testing it seems that rgdal returns "GDAL Error 1: No
field definitions found for 'geo_li_tracts', is it a table?" when it
can't find the table, and returns "Layer not found" when it *can* find
the table, but the table is not registered in geometry_columns.

Interstingly, while specifying public.table_name in SQL is harmless,
when I tried it in rgdal, I got the "Layer not found" error, even though
the table was properly registered in geometry_columns.

--Lee

-- 
Lee Hachadoorian
PhD Student, Geography
Program in Earth & Environmental Sciences
CUNY Graduate Center

On 10/21/2010 08:44 PM, Ben Madin wrote:
> the public. bit refers to the database schema - not something you probably wanted or needed to know, but ironically the clue to the problem - it seems that the tables had at some point (I'm not sure why or how, but I'm doing a few late nights) migrated to the public schema, but they were registered in the geometry columns table as being in the gms. schema. the ogrinfo looked for them, but couldn't find them, and just returned the full list of tables.
> 
> It seems that the R ogrInfo() might have stopped if they weren't in the geometry columns table. I don't know why, but they are now all in the same schema and it seems happy enough. Specifying the different schemas in the dsn (schemas=gms,public) didn't seem to overcome this issue.