QGIS » QGIS Application

Hi Brian,

you can consult the expected roadmap for SpatiaLite 3.0x
(this including any update for the QGIS data provider) on
the SpatiaLite's own ML. please see:
http://groups.google.com/group/spatialite-users/browse_thread/thread/4f206ceb6d934dc2#
(my answer to Volker Froelich on Tue, 10 Jan 2012 17:45:43)

very shortly said:
1) we need to definitively fix 3.0x before
2) updating the QGIS data provider will then follow immediately afterwards

bye Sandro

wonderful, thanks!

Short recall:
- QGIS has its own SpatiaLite data provider: this is intended
to be safely operable using any version of libspatialite
- and in turns libspatialite depends on few other libraries:
libsqlite, libproj, libgeos_c, libgeos, libiconv [libfreeexl]

mainly for historical reasons QGIS includes a "private internal
copy" of libspatialite-amalgamation (which in turn supports a
private internal copy of libsqlite).
few years ago this one seemed a reasonable solution to be
adopted, simply because libspatialite wasn't supported at all
on many platforms, and libsqlite too was unconsistently supported:
using private internal copies obviously resolved this issue.

anyway such solution isn't neither elegant nor safe (as confirmed
by direct field experience): QGIS is a very complex package with
ramified dependencies (this including Python). so a real risk
to deploy many different (and conflicting) libsqlite and libspatialite
versions exists, thus causing troubles and stability issues.

the obvious solution is to never use the internal copies of libsqlite
and libspatialite internally shipped by QGIS.
using the "system-wide" versions of both libraries is a much better
design choice, always ensuring consistent usage of the same dynamic
library version for any possible package/component.

nowadays both libspatialite/libsqlite are decently supported on many
Linux distros; and have recently been supported by OsGeo4W too.
so there is absolutely no good reason suggesting to still continue
using the doomed "internal copies": their usage should be considered
as highly deprecated and intrinsically unsafe.

accordingly to all the above considerations, I suppose that completely
removing any "internal copy" from QGIS (so effectively imposing to always
use system-wide dynamic libraries) should be a really good idea.

Linux and Windows are fine with this. What's the situation on OS X?

Hi Jürgen,

I fully agree with your considerations: pyspatialite seems to be
a key component, because QGIS strongly relies on Python modules.
Please note: I'm not the developer of pyspatialite: he's Lokkju
Brennr <[email protected]>

It's really a pity that Debian-GIS doesn't support pyspatialite:
I'll try to ask Francesco P. Lovergine <[email protected]> about
this; may well be this could resolve (hope well ...)

I've not yet tested the most recent version of pyspatialite; anyway,
if I correctly remember, the pyspatialite own build script was rather
problematic, and surely requiring substantial adjustments:
- it pretended to download libspatialite-amalgamation sources from the
download site before attempting to build
- it required the amalgamation (no attempt to locate external libsqlite3)
I imagine that only Lokkju could fix such issues.

Sandro Furieri wrote:

It's really a pity that Debian-GIS doesn't support pyspatialite:
I'll try to ask Francesco P. Lovergine <[email protected]> about
this; may well be this could resolve (hope well ...)

David Paleino <[email protected]> is already working on a package (in Debian-GIS)

I imagine that only Lokkju could fix such issues.

I didn't check the latest version either, but we have an internal pyspatialite too - that was what I meant to "keep for now".

Jürgen Fischer wrote:

David Paleino <[email protected]> is already working on a package (in Debian-GIS)

See also pyspatialite_3.0.1-2_i386.changes ACCEPTED into unstable

Jürgen Fischer wrote:

Linux and Windows are fine with this. What's the situation on OS X?

At least for my builds (and from source based on the INSTALL instructions), I don't use the internal spatialite. My SQLite framework includes spatialite. It also includes pyspatialite simply as an symlink to pysqlite.

Others who build from source with the package managers (fink, macports) probably have spatialite, maybe pyspatialite (at least pysqlite).

following Williams's suggestions, I've just performed few tests
about the pysqlite connector; here are my findings.

from pysqlite2 import dbapi2 as db
con = db.connect(':memory:')
con.enable_load_extension(True)
con.load_extension('libspatialite.so')
con.execute('select InitSpatialMetadata()')
for row in con.execute('select * from spatial_ref_sys'):
    print row

the above code snippet nicely works on both Debian and Mint
(and I easily imagine on Ubuntu as well); accordingly to
William, the same seems to be for Mac Os X.
so it looks like there is absolutely no real reason suggesting
to use the specialized pyspatialite connector on these systems.

anyway I've got an unexpected failure on Fedora 16:
"enable_load_extension is not supported"
and I've got a second failure on Windows, using the Python
console shipped within the OsGeo4W supplied most recent QGIS
nightly build: "unknown package: pysqlite2"

support for the pysqlite2 connector apparently seems to be
rather whimsical and erratic, and not at all consistent
between different platforms ... a really unpleasant condition.

and a real pity too, because simply using pysqlite2 thus
completely avoiding to use pyspatialite will surely be
a real progress IMHO

As far as Fedora is concerned:

http://groups.google.com/group/spatialite-users/browse_thread/thread/51450b1a61d8cc33/0a733537cbabbad0?show_docid=0a733537cbabbad0

I assume you mean reenabling it just for the distro who ship old SL, right?

Paolo Cavallini wrote:

I assume you mean reenabling it just for the distro who ship old SL, right?

right.