[QGIS-Developer] QGIS3 QgsField : adding DATE / DATETIME / BLOB support

[Mark Johnson]

>> what are your thoughts on
http://osgeo-org.1560.x6.nabble.com/Future-of-spatialite-provider-td5311979.
html
?

For gpkg: should remain solely with OGR.

For VectorLayers (SpatialTables and SpatialViews) is more problematic,
since OGR does not support writable SpatialViews, which I use heavily.

So that would be a -1 for me for removing QgsSpatiaLiteProvider.

With the upcoming Spatialite 4.5.0, with the new RasterLite2 and Topology
support, an adapted QgsSpatiaLiteProvider can provide more than the
present VectorLayers
support.

Since with RasterLite2 one Database will contain both Vector and Raster
Layers and new Dialog logic is needed when selecting Layers to load.
The intention is to create a Dialog that will be similar to that used in
spatialite_gui, where Vector and Raster Layers are separated.
Also the 'hiding' of the Administration tables (that also contain
geometries) is needed to avoid confusion.

Since RasterLite2 is not only designed to store and show Rasters, but also
to combine the Raster-Data with Vector-Data (with SLD/SE styles), an
adapted QgsSpatiaLiteProvider would be more able to utilized to full
functionality than (possibly) GDAL/OGR.

This assumes that the QgsSpatiaLiteProvider is properly maintained and that
changes be made with coordination and discussion with the spatialite
project (which in the past has not been done).

So for QGIS3, I would say, that an option should be built in so that the
User can chose whether the spatialite or Gdal/Ogr provider should be used
in Drag and Drop actions (or other types of file selections).
The present QgsSqliteHandle class can very swiftly determine if a selected
file is supported by the QgsSpatiaLiteProvider or not (and could be
dealt with in QgisApp::handleDropUriList).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170529/0b79fe06/attachment.html>