>> 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
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
