<div dir="ltr">>> Do you have a link to the issues? Does it ignore them or worse?<div><br></div><div>The original report was 3 years ago and is still active:</div><div><br></div><div><a href="https://issues.qgis.org/issues/12479">https://issues.qgis.org/issues/12479</a></div><div><br></div><div>It was also a topic of a QGIS Grant Applications - August 2016</div><div>'Correction of QgsOgrProvider implementaion of GDAL 2.0'</div><div><br></div><div>A pull request was offered about Oct/Nov 2016 for Qgis 2.18 so that the corrected code would be used for the start of Qgis 3.0 - but refused because it was considered an api change.</div><div><br></div><div>Around April 2017 I saw that in Qgis 3.0 had still not been corrected, despite the many changes that had been made.</div><div><br></div><div>Up to then I had been using a gdal version adapted to support writable SpatialViews, that had not been accepted by gdal. But due to the evolvement of gdal was becoming to difficult to maintain.</div><div><br></div><div>Around June I started work on the Spatialite-Provider, with consultations with Alessandro Furieri (Sandro) of the Spatialite project about the future needs, of what is now being termed, as Spatialite 5.0.</div><div><br></div><div>>> Having you all on the same code base is a neat solution I think.</div><div>Not when the 1 Provider (Ogr) will only offer partial results.</div><div>Writable SpatialView has existed since Spatialite 2.4 (we now have 4.3) and there is no sign that Ogr will support this in the near future.</div><div><br></div><div>With Spatialite 5.0, where the world of Vector/Rasters, with Se/Sld Styles are being brought togeather, this will become more difficult to deal with with the separated gdal/ogr providers for all aspects of what can be done.</div><div><br></div><div>>> the amount of work to review the massive PRs was a limiting factor to have that merged.</div><div>>> Do you have plans to ease that review process?</div><div>At the moment I am completing the last stage (of originally 4 stages) of development (Database Maintenance, adding/renaming of columns etc.).</div><div><br></div><div>I have also started work on a Pdf which should help as an orientation as to what the changes are and the reasons why. </div><div>One point I wrote this morning is: 'The Spatialite 5.0 Layout is similar in nature to WMS/WFS 'getCapabilities', combining Vector, Raster and Se/Sld-Styles.'</div><div><br></div><div>One goal is that such a Pdf should assist any reviewer who is willing to work through this.</div><div><br></div><div>A major problem is also, that since Spatialite 5 has not yet been release, it is difficult to understand why these massive changes are needed. So the reluctance it is no surprise to me. </div><div><br></div><div>But the facts remain:</div><div>a) The present Spatialite-Provider is better than the Ogr support for Spatialite</div><div>b) The present Spatialite-Provider will not be able deal will with what Spatialite 5 offers</div><div><br></div><div>Although I myself am not a co-developer of Spatialite (more like a collaborator), I intend to keep this up to-date with future developments. It is also likely that Sandro will take a closer look after the present development phase is over. </div><div><br></div><div>Mark Johnson, Berlin Germany</div><div><br></div><div><br></div><div><br></div><div><br><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre></div></div>