Bug report #12510
plugins using spatialite-amalgamation, pyspatialite
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Build/Install | ||
| Affected QGIS version: | 2.8.1 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 20656 |
Description
Yesterday a problem was reported on the the spatialite site about pyspatialite.
https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!topic/spatialite-users/anQTy_YyqKg
In this case the probable cause was a missing proj4 installation.
while going though this, I saw that many qgis plugins use pyspatialite
- DBManager and Qspatialite
Looking at the pyspatialite code, I saw that it used a built in libspatialite-amalgamation-3.0.1.
The spatialite project, for many years,has discouraged the further use of these amalgamation.
To make matters worse, Qspatialite offers to repair 'faulty' spatialite-db's, that are in reality valid 4.* Databases.
- when doing so, it invokes a (3.0.1) initspatialmetadata() supplied from pyspatialite
For this reason, I would suggest that a plugin using a hardcoded libspatialite-amalgamation be depreciated or removed altogether.
At least there should be a WARNING, that these plugins were designed only for databases created with spatialite up-to 3.0.1 and could cause the db to be malformed (mixed 3.0.1 and 4.0 internal structures).
- none of these plugins give ANY information for which version it was designed for.
I have created and issue at:
https://github.com/lokkju/pyspatialite/issues/23
which I hope is the main site for pyspatialite, advising them that they should remove the libspatialite-amalgamation and used the locally installed sqlite/spatialite version.
As for 'Qspatialite':
- if they don't maintain there 'repair' code, they should remove it
-- they are checking for a field, that only existed until 3.0.1 - so it is NOT being maintained
The spatialite api can, in most cases, deal very well with its older versions
- but as log as the hardcodes 3.0.1 is used pyspatialite, there is no chance of this being done correctly
History
#1
Updated by Jürgen Fischer about 9 years ago
- Resolution set to up/downstream
- Status changed from Open to Feedback
How is this a qgis problem? The pyspatialite and qspatialite shipped with qgis is build with the same version of spatialite that qgis uses - which usually is the version the system uses (if it is uptodate enough). If the system has pyspatialite or qspatialite we use that, but that should also use the same version as qgis uses. If pyspatialite or qspatialite don't use the system's spatialite I'd consider it a packaging problem of those packages and not qgis'.
#2
Updated by Mark Johnson about 9 years ago
Fair enough.
I looked in my plugin directory of the installed qgis and could not find it, so looked at the source listed in the original link.
The version used in the qgis source tree does NOT use the amalgamation, so that is ok.
If qgis uses a system version of pyspatialite that comes from:
https://github.com/lokkju/pyspatialite
then that version will cause problems because the 3.0.1 amalgamation is compiled directly into the source.
The comments on qspatialite, are based on the last installed on my machine (2011-03-15)
#3
Updated by Jürgen Fischer about 9 years ago
- Status changed from Feedback to Closed
- Category changed from C++ Plugins to Build/Install
On current debian and osgeo4w pyspatialite uses the same version as QGIS.