QGIS is using Spatialite 4. If I execute SELECT spatialite_version() in DB Manger, I get 4.0.0.
The problem with creating a new layer is that with SpatiaLite 4, QGIS will not load an empty table. The debug info shows: Debug: src/providers/spatialite/qgsspatialiteprovider.cpp: 523: (QgsSpatiaLiteProvider) Invalid SpatiaLite layer The database and table appears to be created correctly. If I use SQL to insert one record with geometry into the table with DB Manager, then I can load the table to the canvas in QGIS. I am using OS X 10.8.3 with QGIS daily builds from Dakota Cartography and frameworks from kygnchaos. SpatiaLite 4.0 appears to work without problems in python programs I have written. The fact that SELECT spatialite_version() in the DB Manager SQL window indicates to me that DB Manger is loading the correct version of pysqlite from the kygnchaos frameworks. Royce On May 22, 2013, at 5:22 AM, [email protected]<mailto:[email protected]> wrote: On Tue, 21 May 2013 13:14:00 -0600, Larry Shaffer wrote: Is anyone using QGIS master branch with Spatialite 4.0 successfully? If Spatialite 4.0 is still not supported yet, is anyone working on it? I can get a vector layer to Save as... to a Spatialite 4.0 db, but can't create a new one. On Tue, 21 May 2013 20:42:35 +0000, Cline, Royce L. wrote: The other issue I have had with SpatiaLite 4 is with DB Manager. DB Manager does not recognize geometry for a table in a Spatialite 4 created database (new spatial metadata). Displays the same as a table without geometry. If the database was created with Spatialite 3 or converted to a version 3 database with spatialite_convert, then it will show the table as having geometry. It would appear that DB Manager is not testing whether the database containing the table is using the new or old version of the spatial metadata. both issues are closely related. since many months the QGIS-spatialite data-provider has been updated so to be able to connect indifferently both spatialite v.3.x and v.4.x DB-files. any specific difference affecting the data layout for Spatial Metadata tables adopted by each version will be always silently handled in the most appropriate way by the revised data-provider. the whole process will be absolutely transparent from the end user POV. the relevant QGIS-trunk cumulative patch corresponds to commit #47097b72 [2012 November 30] anyway, simply updating the data-provider code itself isn't enough in order to effectively activate full support for v.4.0.0 DB-files: a) QGIS binaries must be absolutely built on the top of libspatialite 4.0.0 (if binaries are actually built on the top of some earlier libspatialite version the whole code implementing 4.0.0 support will be conditionally disabled by CMAKE) b) at run time QGIS must effectively load libspatialite 4.0.0 (or any later version) if one or the other of these two conditions aren't satisfied, then QGIS will be completely unable to access any DB-file created by libspatialite 4.0.0 so the real issue is in that quite almost Linux major distros still support obsolete versions of libspatialite; the same is true for the OSGeo4W Win distro. the net result of this situation is that even building a fresh copy of QGIS-trunk starting from sources will easily produce an executable binary completely unable to support v.4.0.0 DB-files. on the other side, building QGIS-trunk after installing a custom built libspatialite-4.x will always create binaries perfectly able to access v.4.0.0 DB-files, even on Windows MSVC/OSGeo4W. ----------------- the second issue (DB Manager) requires few more considerations. Spatialite (exactly as PostGIS) supports several "high-level/abstract" SQL functions allowing to correctly handle Spatial Metadata tables in the most transparent way; such an approach is obviously intended to shield against fine-grained implementation details, which can easily change from version to version. case A) if the developer always correctly invoked the expected "high level" SQL functions, then transitioning from v.3 to v.4 is expected to be a completely painless process; because in this case the underlying library will silently accommodate for any possible physical data layout difference introduced by the most recent version. case B) on the other hand, if the developer decided to completely skip using any appropriate "abstract" SQL function so to directly perform some INSERT or UPDATE statement affecting the Spatial Metadata tables, many painful transition issues should be expected to arise while transitioning to the most recent version. in this case a patient code correction action has obviously to be applied case by case. I strongly fear that this second (worst) case is the most probable scenario we can expect to face for DB Manager (and possibly for others plug-ins). bye Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ Qgis-developer mailing list [email protected]<mailto:[email protected]> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
