Hi Even,
2014-07-11 11:33 GMT+02:00 Even Rouault :
> If you see the CREATE TABLE in the debug log, and it is not created, then it
> is
> really weird. Perhaps check the potential surrounding BEGIN/COMMIT/ROLLBACK
> just
> in case. Might it not be an issue with your PostgreSQL instance ?
I trie
Selon Martin Landa :
> Hi,
>
> 2014-07-11 9:07 GMT+02:00 Martin Landa :
> > It's random, usually one or two layers are missing in output DB...
>
> I checked also all tables with
>
> psql vfr -c "SELECT * FROM information_schema.tables WHERE
> table_schema = 'public'"
>
> Some tables (one or two) a
Hi,
2014-07-11 9:07 GMT+02:00 Martin Landa :
> It's random, usually one or two layers are missing in output DB...
I checked also all tables with
psql vfr -c "SELECT * FROM information_schema.tables WHERE
table_schema = 'public'"
Some tables (one or two) are simply not written for unknown reason
Hi,
2014-07-10 11:32 GMT+02:00 Even Rouault :
> I would say that your Zsj layer is a non-spatial layer. Is it the case ?
no, all layers are spatial.
> If yes, then the output of the log and the content of geometry_columns are
> consistant. You may not see it directly when running ogrinfo on the
Hi Martin,
I would say that your Zsj layer is a non-spatial layer. Is it the case ?
If yes, then the output of the log and the content of geometry_columns are
consistant. You may not see it directly when running ogrinfo on the PostGIS DB
since by default only spatial layers are listed. You can how
Hi all,
I have a Python script which converts data from GML (VFR) to PostGIS.
When I am overwriting existing layers in PostGIS, not all layers are
really created. First existing layers are deleted [1] and than created
[2] from scratch.
Steps to reproduce (`git clone https://github.com/landam/ogr-
