[Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Cline, Royce L.]

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, a.furieri at lqt.it<mailto:a.furieri at lqt.it> 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
Qgis-developer at lists.osgeo.org<mailto:Qgis-developer at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130522/afe08a61/attachment-0001.html>