[gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Hi, There are no GUI-tools for managing GeoPackage databases at the moment and because after all they are only SQLite db files just like Spatialite files I thought it would be a good idea to do some maintenance work for GPKG database with Spatialite-gui. I could do a few things with Spatialite-gui without troubles: create a view, create an index, add column. But then I renamed one table and after that I cannot use the DB file with GPKG driver any more. SQLite driver does open it but db is unusable because the geometry BLOBs are different. I have received two king of error messages from ogrinfo and also a sudden program crash. One error message is: ogrinfo test.gpkg ERROR 1: bad application_id on 'test.gpkg' ERROR 1: bad application_id on 'test.gpkg' FAILURE: Unable to open datasource `test.gpkg' with the following drivers. Another message is: ogrinfo test.gpkg ERROR 1: (null) INFO: Open of `test.gpkg' using driver `GPKG' successful. To reproduce the error create a GeoPackage with GDAL, open it with Spatialite-gui and rename one table. I know it is perhaps not a good idea to rename a GeoPackage table with "ALTER TABLE ... RENAME TO ..." because it breaks the integrity, but on the other hand, because it seems to be possible to do so without any triggers and constraints preventing the operation and the result is an unusable database it could be worth having a look on what happens. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Jukka, I highly suspect that the ALTER TABLE must imply a rewriting of the file by spatialite/spatialite-gui, and when doing so, it doesn't preserve the "application id" (4 bytes in the header of sqlite file), that geopackage specification mentions to be set to a particular value. Consequently the geopackage driver later fails when checking the signature. A few inline comments below > Hi, > > There are no GUI-tools for managing GeoPackage databases at the moment and > because after all they are only SQLite db files just like Spatialite files I > thought it would be a good idea to do some maintenance work for GPKG > database with Spatialite-gui. > > I could do a few things with Spatialite-gui without troubles: create a view, > create an index, add column. But then I renamed one table and after that I > cannot use the DB file with GPKG driver any more. SQLite driver does open it > but db is unusable because the geometry BLOBs are different. I have received > two king of error messages from ogrinfo and also a sudden program crash. One > error message is: > > ogrinfo test.gpkg > ERROR 1: bad application_id on 'test.gpkg' > ERROR 1: bad application_id on 'test.gpkg' > FAILURE: > Unable to open datasource `test.gpkg' with the following drivers. Yes, that's expected if the application id has been changed. That one doesn't cause a program crash, right ? > > Another message is: > ogrinfo test.gpkg > ERROR 1: (null) > INFO: Open of `test.gpkg' > using driver `GPKG' successful. --> Hum, "ERROR 1: (null)" means a NULL pointer used as a string somewhere and a potential source for crashing. > > To reproduce the error create a GeoPackage with GDAL, open it with > Spatialite-gui and rename one table. I know it is perhaps not a good idea to > rename a GeoPackage table with "ALTER TABLE ... RENAME TO ..." because it > breaks the integrity, but on the other hand, because it seems to be possible > to do so without any triggers and constraints preventing the operation and > the result is an unusable database it could be worth having a look on what > happens. > > -Jukka Rahkonen- > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Even Rouault mines-paris.org> writes: > > Jukka, > > I highly suspect that the ALTER TABLE must imply a rewriting of the file by > spatialite/spatialite-gui, and when doing so, it doesn't preserve the > "application id" (4 bytes in the header of sqlite file), that geopackage > specification mentions to be set to a particular value. Consequently the > geopackage driver later fails when checking the signature. I have not yet found a way to reproduce crash in a reliable way but while testing I found something else. Does the following mean that the GPKG file is not totally valid SQLite file or just that GDAL gets puzzled because there are separate implementations for SQLite/Spatialite and GPKG? Step 1: create plain SQLite and GPKG databases C:\data>ogr2ogr -f sqlite test.sqlite temp.shp C:\data>ogr2ogr -f gpkg test.gpkg temp.shp Step 2: try to rename a table C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp rename to temp2" INFO: Open of `test.sqlite' using driver `SQLite' successful. C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp rename to temp2" INFO: Open of `test.gpkg' using driver `GPKG' successful. ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename to temp2): no such table: temp I noticed that OGR dialect does not support renaming tables, it suggests to rename a column instead. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Selon Jukka Rahkonen : > Even Rouault mines-paris.org> writes: > > > > > Jukka, > > > > I highly suspect that the ALTER TABLE must imply a rewriting of the file by > > spatialite/spatialite-gui, and when doing so, it doesn't preserve the > > "application id" (4 bytes in the header of sqlite file), that geopackage > > specification mentions to be set to a particular value. Consequently the > > geopackage driver later fails when checking the signature. > > I have not yet found a way to reproduce crash in a reliable way but while > testing I found something else. Does the following mean that the GPKG file > is not totally valid SQLite file or just that GDAL gets puzzled because > there are separate implementations for SQLite/Spatialite and GPKG? > > > Step 1: create plain SQLite and GPKG databases > > C:\data>ogr2ogr -f sqlite test.sqlite temp.shp > C:\data>ogr2ogr -f gpkg test.gpkg temp.shp > > Step 2: try to rename a table > C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp rename to > temp2" > INFO: Open of `test.sqlite' > using driver `SQLite' successful. > > C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp rename to > temp2" > INFO: Open of `test.gpkg' > using driver `GPKG' successful. > ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename to temp2): > no such table: temp Hum, well I can see that you are going to run into problems. The GPKG driver has no ExecuteSQL() implementation that should directly handle your SQL requests (what the SQLite driver would do). So it fallbacks to the generic ExecuteSQL() implementation, which uses the sqlite VirtualOGR mechanism, which does not support table renaming. Ideally, the GPKG driver should be extended to implement ExecuteSQL() in a similar way than the SQLite driver. > > I noticed that OGR dialect does not support renaming tables, it suggests to > rename a column instead. > > -Jukka- > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
On Mon, 17 Feb 2014 16:14:39 +0100, Even Rouault wrote: Jukka, I highly suspect that the ALTER TABLE must imply a rewriting of the file by spatialite/spatialite-gui, and when doing so, it doesn't preserve the "application id" (4 bytes in the header of sqlite file), that geopackage specification mentions to be set to a particular value. Consequently the geopackage driver later fails when checking the signature. the current version of spatialite-gui doesn't offerts any support to GPKG; Brad Hards has recently added few GPKG oriented-APIs into libspatialite-4.2.0-devel, but this only affects the library. the GUI-tool itself *always* assumes it's processing a genuine spatialite DB-file. I could do a few things with Spatialite-gui without troubles: create a view, create an index, add column. But then I renamed one table and after that I cannot use the DB file with GPKG driver any more. Jukka, if you had actually invoked the user friendly dialog box "rename table" it's not at all surprising discovering that you've simply introduced some fatal corruption in your DB the spatialite_gui tool is strictly intended to support "genuine SpatiaLite DB-files"; I strongly fear that any attempt to use this highly specialized tool on behalf of some GPKG-file would simply end in disasters. some future version of the GUI tool will surely implement some kind of GPKG support: but for now using the current version on any GPKG-file surely is a risky and unsafe business. bye Sandro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Hi, Is this the same issue about how GPKG is handling ExecuteSQL()? If it is, then I will make a ticket because a database without indexes is missing a lot. Or is there some other way how I could create index into GPKG with GDAL? Alessandro Furieri told already that using spatialite-gui/tools for GeoPackages is currently not safe. ogrinfo test.gpkg -dialect sqlite -sql "create index knro_idx on test (knro)" INFO: Open of `test.gpkg' using driver `GPKG' successful. ERROR 1: In ExecuteSQL(): sqlite3_prepare(create index knro_idx on test (knro)): no such table: main.test -Jukka- Even Rouault wrote: > > Selon Jukka Rahkonen : > > > Even Rouault mines-paris.org> writes: > > > > > > > > Jukka, > > > > > > I highly suspect that the ALTER TABLE must imply a rewriting of the > > > file by spatialite/spatialite-gui, and when doing so, it doesn't > > > preserve the "application id" (4 bytes in the header of sqlite > > > file), that geopackage specification mentions to be set to a > > > particular value. Consequently the geopackage driver later fails when > checking the signature. > > > > I have not yet found a way to reproduce crash in a reliable way but > > while testing I found something else. Does the following mean that the > > GPKG file is not totally valid SQLite file or just that GDAL gets > > puzzled because there are separate implementations for SQLite/Spatialite and > GPKG? > > > > > > Step 1: create plain SQLite and GPKG databases > > > > C:\data>ogr2ogr -f sqlite test.sqlite temp.shp C:\data>ogr2ogr -f > > gpkg test.gpkg temp.shp > > > > Step 2: try to rename a table > > C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp > > rename to temp2" > > INFO: Open of `test.sqlite' > > using driver `SQLite' successful. > > > > C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp > > rename to temp2" > > INFO: Open of `test.gpkg' > > using driver `GPKG' successful. > > ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename to temp2): > > no such table: temp > > Hum, well I can see that you are going to run into problems. The GPKG driver > has > no ExecuteSQL() implementation that should directly handle your SQL requests > (what the SQLite driver would do). So it fallbacks to the generic ExecuteSQL() > implementation, which uses the sqlite VirtualOGR mechanism, which does not > support table renaming. > Ideally, the GPKG driver should be extended to implement ExecuteSQL() in a > similar way than the SQLite driver. > > > > > I noticed that OGR dialect does not support renaming tables, it > > suggests to rename a column instead. > > > > -Jukka- > > > > ___ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Hi Jukka, yes, this is the same issue. -dialect sqlite is quite powerfull, but can only handle SELECT / UPDATE / DELETE, no other fancy stuff. The GPKG driver should just have its ExecuteSQL() implementation. Currently I guess you could open a .gpkg with the sqlite3 binary. I wouldn't expect it to alter the application_id field (or perhaps in the same situation as spatialite_gui does). Even > Hi, > > Is this the same issue about how GPKG is handling ExecuteSQL()? If it is, > then I will make a ticket because a database without indexes is missing a > lot. Or is there some other way how I could create index into GPKG with GDAL? > Alessandro Furieri told already that using spatialite-gui/tools for > GeoPackages is currently not safe. > > ogrinfo test.gpkg -dialect sqlite -sql "create index knro_idx on test (knro)" > INFO: Open of `test.gpkg' > using driver `GPKG' successful. > ERROR 1: In ExecuteSQL(): sqlite3_prepare(create index knro_idx on test > (knro)): > no such table: main.test > > -Jukka- > > Even Rouault wrote: > > > > Selon Jukka Rahkonen : > > > > > Even Rouault mines-paris.org> writes: > > > > > > > > > > > Jukka, > > > > > > > > I highly suspect that the ALTER TABLE must imply a rewriting of the > > > > file by spatialite/spatialite-gui, and when doing so, it doesn't > > > > preserve the "application id" (4 bytes in the header of sqlite > > > > file), that geopackage specification mentions to be set to a > > > > particular value. Consequently the geopackage driver later fails when > > checking the signature. > > > > > > I have not yet found a way to reproduce crash in a reliable way but > > > while testing I found something else. Does the following mean that the > > > GPKG file is not totally valid SQLite file or just that GDAL gets > > > puzzled because there are separate implementations for SQLite/Spatialite > and > > GPKG? > > > > > > > > > Step 1: create plain SQLite and GPKG databases > > > > > > C:\data>ogr2ogr -f sqlite test.sqlite temp.shp C:\data>ogr2ogr -f > > > gpkg test.gpkg temp.shp > > > > > > Step 2: try to rename a table > > > C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp > > > rename to temp2" > > > INFO: Open of `test.sqlite' > > > using driver `SQLite' successful. > > > > > > C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp > > > rename to temp2" > > > INFO: Open of `test.gpkg' > > > using driver `GPKG' successful. > > > ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename to > temp2): > > > no such table: temp > > > > Hum, well I can see that you are going to run into problems. The GPKG > driver has > > no ExecuteSQL() implementation that should directly handle your SQL > requests > > (what the SQLite driver would do). So it fallbacks to the generic > ExecuteSQL() > > implementation, which uses the sqlite VirtualOGR mechanism, which does not > > support table renaming. > > Ideally, the GPKG driver should be extended to implement ExecuteSQL() in a > > similar way than the SQLite driver. > > > > > > > > I noticed that OGR dialect does not support renaming tables, it > > > suggests to rename a column instead. > > > > > > -Jukka- > > > > > > ___ > > > gdal-dev mailing list > > > gdal-dev@lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Hi, Creating indexes with sqlite3 feels safe. Renaming table is unsafe and leads to ogrinfo crash. sqlite> alter table test rename to test2; C:\ohjelmat\sqlite3>ogrinfo kuti.gpkg ERROR 1: (null) INFO: Open of `kuti.gpkg' using driver `GPKG' successful. Next: Crash. What is good is that everything is good again after doing sqlite> alter table test2 rename to test; Renaming a table is not something that is absolutely needed but it is not a totally odd idea either and it should not lead to program crash. Now it looks like the crash comes from metadata and real table names being unsynchronized and a proper way to support renaming the tables would mean creating also triggers into the database for updating the metadata fields correctly. Because it is sure at the moment that renaming a table will lead to a not usable GeoPackage it might be good to mention it in the Limitations section of driver page http://www.gdal.org/ogr/drv_geopackage.html -Jukka- > -Alkuperäinen viesti- > Lähettäjä: Even Rouault [mailto:even.roua...@mines-paris.org] > Lähetetty: 18. helmikuuta 2014 11:07 > Vastaanottaja: Rahkonen Jukka (Tike) > Kopio: 'gdal-dev@lists.osgeo.org' > Aihe: Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui > > Hi Jukka, > > yes, this is the same issue. -dialect sqlite is quite powerfull, but can only > handle > SELECT / UPDATE / DELETE, no other fancy stuff. The GPKG driver should just > have its ExecuteSQL() implementation. > Currently I guess you could open a .gpkg with the sqlite3 binary. I wouldn't > expect it to alter the application_id field (or perhaps in the same situation > as > spatialite_gui does). > > Even > > > Hi, > > > > Is this the same issue about how GPKG is handling ExecuteSQL()? If it > > is, then I will make a ticket because a database without indexes is > > missing a lot. Or is there some other way how I could create index into GPKG > with GDAL? > > Alessandro Furieri told already that using spatialite-gui/tools for > > GeoPackages is currently not safe. > > > > ogrinfo test.gpkg -dialect sqlite -sql "create index knro_idx on test > > (knro)" > > INFO: Open of `test.gpkg' > > using driver `GPKG' successful. > > ERROR 1: In ExecuteSQL(): sqlite3_prepare(create index knro_idx on > > test > > (knro)): > > no such table: main.test > > > > -Jukka- > > > > Even Rouault wrote: > > > > > > Selon Jukka Rahkonen : > > > > > > > Even Rouault mines-paris.org> writes: > > > > > > > > > > > > > > Jukka, > > > > > > > > > > I highly suspect that the ALTER TABLE must imply a rewriting of > > > > > the file by spatialite/spatialite-gui, and when doing so, it > > > > > doesn't preserve the "application id" (4 bytes in the header of > > > > > sqlite file), that geopackage specification mentions to be set > > > > > to a particular value. Consequently the geopackage driver later > > > > > fails when > > > checking the signature. > > > > > > > > I have not yet found a way to reproduce crash in a reliable way > > > > but while testing I found something else. Does the following mean > > > > that the GPKG file is not totally valid SQLite file or just that > > > > GDAL gets puzzled because there are separate implementations for > > > > SQLite/Spatialite > > and > > > GPKG? > > > > > > > > > > > > Step 1: create plain SQLite and GPKG databases > > > > > > > > C:\data>ogr2ogr -f sqlite test.sqlite temp.shp C:\data>ogr2ogr -f > > > > gpkg test.gpkg temp.shp > > > > > > > > Step 2: try to rename a table > > > > C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp > > > > rename to temp2" > > > > INFO: Open of `test.sqlite' > > > > using driver `SQLite' successful. > > > > > > > > C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp > > > > rename to temp2" > > > > INFO: Open of `test.gpkg' > > > > using driver `GPKG' successful. > > > > ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename > > > > to > > temp2): > > > > no such table: temp > > > > > > Hum, well I can see that you are going to run into problems. The > > > GPKG > > driver has >
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Selon "Rahkonen Jukka (Tike)" : > Hi, > > Creating indexes with sqlite3 feels safe. Renaming table is unsafe and leads > to ogrinfo crash. > > sqlite> alter table test rename to test2; > > C:ohjelmatsqlite3>ogrinfo kuti.gpkg > ERROR 1: (null) > INFO: Open of `kuti.gpkg' > using driver `GPKG' successful. > > Next: Crash. > > What is good is that everything is good again after doing > sqlite> alter table test2 rename to test; > > Renaming a table is not something that is absolutely needed but it is not a > totally odd idea either and it should not lead to program crash. Now it looks > like the crash comes from metadata and real table names being unsynchronized > and a proper way to support renaming the tables would mean creating also > triggers into the database for updating the metadata fields correctly. > Because it is sure at the moment that renaming a table will lead to a not > usable GeoPackage it might be good to mention it in the Limitations section > of driver page http://www.gdal.org/ogr/drv_geopackage.html I share your analysis. This is likely a lack of robustness when a table name found in the metadata tables (like gpkg_contents) does not exist. I've not checked if sqlite triggers could be used to update gpkg_contents accordingly, which would be the right thing to do if doable. But anyway sqlite triggers can be disabled by applications, so the driver ought to be robust for that. This is IMHO worth a ticket. Please add pramsey in CC of the ticket Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Apolgies up-front for the self promotion... Jukka, If you need a basic geopackage enabled sqlite shell, you can compile https://bitbucket.org/luciad/libgpkg to get this. One of the outputs is the 'gpkg' binary which is the sqlite shell with the libgpkg extension preloaded. This is nowhere near as featureful as ogr or spatialite, but should already allow you to do basic CLI geopackage management. Regards, Pepijn On 18-02-14 10:46, Rahkonen Jukka (Tike) wrote: Hi, Creating indexes with sqlite3 feels safe. Renaming table is unsafe and leads to ogrinfo crash. sqlite> alter table test rename to test2; C:\ohjelmat\sqlite3>ogrinfo kuti.gpkg ERROR 1: (null) INFO: Open of `kuti.gpkg' using driver `GPKG' successful. Next: Crash. What is good is that everything is good again after doing sqlite> alter table test2 rename to test; Renaming a table is not something that is absolutely needed but it is not a totally odd idea either and it should not lead to program crash. Now it looks like the crash comes from metadata and real table names being unsynchronized and a proper way to support renaming the tables would mean creating also triggers into the database for updating the metadata fields correctly. Because it is sure at the moment that renaming a table will lead to a not usable GeoPackage it might be good to mention it in the Limitations section of driver page http://www.gdal.org/ogr/drv_geopackage.html -Jukka- -Alkuperäinen viesti- Lähettäjä: Even Rouault [mailto:even.roua...@mines-paris.org] Lähetetty: 18. helmikuuta 2014 11:07 Vastaanottaja: Rahkonen Jukka (Tike) Kopio: 'gdal-dev@lists.osgeo.org' Aihe: Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui Hi Jukka, yes, this is the same issue. -dialect sqlite is quite powerfull, but can only handle SELECT / UPDATE / DELETE, no other fancy stuff. The GPKG driver should just have its ExecuteSQL() implementation. Currently I guess you could open a .gpkg with the sqlite3 binary. I wouldn't expect it to alter the application_id field (or perhaps in the same situation as spatialite_gui does). Even Hi, Is this the same issue about how GPKG is handling ExecuteSQL()? If it is, then I will make a ticket because a database without indexes is missing a lot. Or is there some other way how I could create index into GPKG with GDAL? Alessandro Furieri told already that using spatialite-gui/tools for GeoPackages is currently not safe. ogrinfo test.gpkg -dialect sqlite -sql "create index knro_idx on test (knro)" INFO: Open of `test.gpkg' using driver `GPKG' successful. ERROR 1: In ExecuteSQL(): sqlite3_prepare(create index knro_idx on test (knro)): no such table: main.test -Jukka- Even Rouault wrote: Selon Jukka Rahkonen : Even Rouault mines-paris.org> writes: Jukka, I highly suspect that the ALTER TABLE must imply a rewriting of the file by spatialite/spatialite-gui, and when doing so, it doesn't preserve the "application id" (4 bytes in the header of sqlite file), that geopackage specification mentions to be set to a particular value. Consequently the geopackage driver later fails when checking the signature. I have not yet found a way to reproduce crash in a reliable way but while testing I found something else. Does the following mean that the GPKG file is not totally valid SQLite file or just that GDAL gets puzzled because there are separate implementations for SQLite/Spatialite and GPKG? Step 1: create plain SQLite and GPKG databases C:\data>ogr2ogr -f sqlite test.sqlite temp.shp C:\data>ogr2ogr -f gpkg test.gpkg temp.shp Step 2: try to rename a table C:\data>ogrinfo test.sqlite -dialect sqlite -sql "alter table temp rename to temp2" INFO: Open of `test.sqlite' using driver `SQLite' successful. C:\data>ogrinfo test.gpkg -dialect sqlite -sql "alter table temp rename to temp2" INFO: Open of `test.gpkg' using driver `GPKG' successful. ERROR 1: In ExecuteSQL(): sqlite3_prepare(alter table temp rename to temp2): no such table: temp Hum, well I can see that you are going to run into problems. The GPKG driver has no ExecuteSQL() implementation that should directly handle your SQL requests (what the SQLite driver would do). So it fallbacks to the generic ExecuteSQL() implementation, which uses the sqlite VirtualOGR mechanism, which does not support table renaming. Ideally, the GPKG driver should be extended to implement ExecuteSQL() in a similar way than the SQLite driver. I noticed that OGR dialect does not support renaming tables, it suggests to rename a column instead. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo
Re: [gdal-dev] GeoPackage fails after touching it with Spatialite-gui
Pepijn Van Eeckhoudt vaneeckhoudt.net> writes: > > Apolgies up-front for the self promotion... > > Jukka, > > If you need a basic geopackage enabled sqlite shell, you can compile > https://bitbucket.org/luciad/libgpkg to get this. One of the outputs is > the 'gpkg' binary which is the sqlite shell with the libgpkg extension > preloaded. This is nowhere near as featureful as ogr or spatialite, but > should already allow you to do basic CLI geopackage management. Hi Pepijn, If you knew me and wanted me to play with your toy (that I for sure would like to do) you would have compiled Windows binaries for downloading. Compile is not what I do, I merely test and complain :) -Jukka- > Regards, > > Pepijn ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
