Spatialite-Provider in QGIS3

[mj10777]

Since there have been questions in the last months about RasterLite2 support in QGIS, I would like to give a general summery of the present situation.

At present, the Spatialite-Provider in QGIS3 is completely outdated.

It was originally designed for the Spatalite Legacy (Versions 2.4 to 3.*) and the Spatialite 4.0 Layout (Versions 4.0 to 4.3).

For the upcoming Spatialite 5.0 Layout, which is designed to support WMS, WFS, and WCS standards,

there is no way that the present Spatialite-Provider in QGIS3 will be capable of dealing with the new layout.

The present Provider deals only with Vectors/Geometries, where as with Spatialite 5.0 it would need to deal with Vectors/Rasters and Styles for both.

At present, the needed collection functions (for Vectors only) are spread out in different classes, some functions are implemented multiple times (in the different classes) and not all of them implemented correctly.

What is needed (and has been done) is for a outside class to collect all the needed information from the Database and to be used as the source for the Vector/Raster Providers.

Since Spatialite 5.0 (and GeoPackage) are the first containers that offer both Vectors/Rasters in one source, the idea of dealing with both in one class is new.

This is the main reason why the new Spatialite/RasterLite2 Providers will not make it into QGIS 3.0.

The QGIS reviewers are all voluntary and themselves engrossed with new, extensive, innovation for QGIS 3.0 for them to properly review the radical changes needed in a responsible matter.

It has, however, been earmarked for QGIS 3.2, which will probably be released a few months after QGIS 3.0.

Initially, last August/September, the plan for the new provider was planed to be implemented in 3 to 4 Phases:

1) Replacement of the present functionality, based on a outside class, called 'QgsSpatialiteDbInfo', which would contain all information about a sqlite3 container that is supported by a QGis-Provider  (Spatialite, RasterLite2,Gdal and Ogr).

Inside 'QgsSpatialiteDbInfo' there is a list of all Layers that a QGis-Provider can display (called 'QgsSpatialiteDbLayer').

For the Spatialite and RasterLite2 Providers: they would use this 'QgsSpatialiteDbLayer', that contains all information needed to render the layer.

The 'QgsSpatialiteDbInfo' would be contained inside the QgsSqliteHandle, which, already existed and make the spatialite connection.

This class had already be designed to be re-useable (i.e. a second connection to the same Database would use the same connection).

If you are loading a project that contains 50 Layers from the same Database, the Database is the read only once.

2) Browser support

this function runs through the files to determine which files contain spatial-data and list all the found layers and add them to the canvas.

3) Data Source Manager

this was a simple list of vector-layers that could could be selected, together with a filter capability.

This has been adapted to look more like the left side spatialite_gui, where there are Sub-Groups for SpatialTables, SpatialViews and where they exist, RasterLite2-Layers, Style and Topologies.

For GeoPackage: a Sub-Group for Vectors and Rasters

For MBTiles; the Raster-Layer (there can only be 1)

Each Layer can be expanded to show at list of the columns, registered Styles (if the exist) and general Metadata about the Layer - each in an extra Sub-Group.

When Layers are selected a second Tab can be seen with the selected Layers. Each Layer can be expanded when styles exist, so that a different style can be selected instead of the default first registered style.

The order of the Layers can be changed, so that when submitted, they will be submitted in that order.

The actual submitting of the Layers to the MapCanvas is done is done in 'QgsSpatialiteDbInfo', where order of Rasters, Polygons, Linestrings and Points insures that the Points will be over the Linestrings, which are over the Polygons, which is over the Rasters.

A third Tab will show the new QgsMetadataWidget with the Layer-Metadata.

That is the present status of the development as of today.

So the next step would be:

Make the QgsMetadataWidget editable

4) A fourth Tab with general Maintenance functions for the Database or Layer, such as 

a) The drop or rename of columns  

-----

Since 'QgsSpatialiteDbInfo' is the backbone of these changes, this cannot be done in smaller steps. 

The reviewers must also judge any side effects it may have on the rest of the project.

For all these reason, waiting until QGIS 3 has been released, where under less pressure, all aspects of the changes can be dealt with, is the wisest approach.

Also the fact that Spatialite 5.0 with RasterLite2 has not yet been released, also adds a good reason for a more patient approach.

Mark