<div dir="ltr"><div><div>Hi Luigi, <br></div>I think you summed up things right. <br><br></div>For the sake of the thread readability, I re-post Mark's answer that for some reason was not considered a response to this thread by the mailman list. <br><br>------<br><br><span class="gmail-post-date gmail-float-left"><span id="gmail-d1519735654000-946">Feb 27, 2018; 1:47pm</span></span><br><br>>> 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" target="_blank">https://issues.qgis.org/issues<wbr>/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></div>-<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-28 11:30 GMT+01:00 Luigi Pirelli <span dir="ltr"><<a href="mailto:luipir@gmail.com" target="_blank">luipir@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree about GDLA/OGR, and are the positions already expressed in the Mark's PR<br>
<br>
but take into account that:<br>
<br>
1) maintainer could be Mark (as for other core plugins e.g.<br>
MetaSearch). I agree that having only a maintainer for a complex core<br>
part can be dangerous for quality of the overall project => agree with<br>
Regis, could be a PSC decision.<br>
2) The code is already there and should overpass some sqlite<br>
limitations not present in spatialite giving professional opportunity<br>
right now (but also reducing the hability to rise funds for a OGR<br>
solution :( )<br>
3) It can be compiled or packaged optionally<br>
4) Marks seems not focusing on work on GDAL/OGR<br>
<br>
btw without reviewers it's hard to have any merge<br>
<span class="im HOEnZb">Luigi Pirelli<br>
<br>
******************************<wbr>******************************<wbr>******************************<wbr>********<br>
* LinkedIn: <a href="https://www.linkedin.com/in/luigipirelli" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>luigipirelli</a><br>
* Stackexchange: <a href="http://gis.stackexchange.com/users/19667/luigi-pirelli" rel="noreferrer" target="_blank">http://gis.stackexchange.com/<wbr>users/19667/luigi-pirelli</a><br>
* GitHub: <a href="https://github.com/luipir" rel="noreferrer" target="_blank">https://github.com/luipir</a><br>
* Mastering QGIS 2nd Edition:<br>
* <a href="https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition" rel="noreferrer" target="_blank">https://www.packtpub.com/big-<wbr>data-and-business-<wbr>intelligence/mastering-qgis-<wbr>second-edition</a><br>
* Hire me: <a href="http://goo.gl/BYRQKg" rel="noreferrer" target="_blank">http://goo.gl/BYRQKg</a><br>
******************************<wbr>******************************<wbr>******************************<wbr>********<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 27 February 2018 at 21:40, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com">apasotti@gmail.com</a>> wrote:<br>
> On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli <<a href="mailto:luipir@gmail.com">luipir@gmail.com</a>> wrote:<br>
>><br>
>> ><br>
>> > On 27/02/2018 11:12, Mark Johnson wrote:<br>
>> >>>> that we get rid of the current provider and rely on GDAL only.<br>
>> >><br>
>> >> With the 'current provider' I assume you mean the Spatialite-Provider.<br>
>> >><br>
>> >> Please remember that the Spatialite-Provider was never designed to<br>
>> >> support GeoPackage.<br>
>> >><br>
>> >> Please also remember that Gdal/Ogr does not support all aspects of<br>
>> >> Spatialite<br>
>> >> - writable SpatialViews are not supported<br>
>> >><br>
>> >> The present QgsOgrProvider does not support Spatialite-Tables with more<br>
>> >> than 1 geometry properly.<br>
>> ><br>
>> > Would it be possible to add these to the QgsOgrProvider, or are there<br>
>> > some limitations ?<br>
>><br>
>> Hi Hugo<br>
>><br>
>> Some technical opinion are available in related PR done by Mark to<br>
>> propose a new Spatialite provider.<br>
>> The general opinion is to check before if it make sense to remove<br>
>> spatialite limitations in the gdal provider to sqlite.<br>
>> There are also opinon that the PR is actually not so simple to review,<br>
>> for the complexity and extension. Oslandia can do it if apport more to<br>
>> his business.<br>
>><br>
>> IMHO I can't see any problem to merge it after review and have a new<br>
>> or parallel spatialite provicer.<br>
>><br>
><br>
> Well, I do: I think that unless there is an overwhelming technical reason to<br>
> take a different route, QGIS should not create alternative providers where<br>
> OGR/GDAL can do the job.<br>
><br>
> The reason is both in how open source works: building wonderful applications<br>
> on top of wonderful libraries (GDAL/OGR in this case) and in how we should<br>
> avoid to enlarge the code base without a valid reason.<br>
><br>
> The right approach in this particular case is IMHO to work with OGR/GDAL to<br>
> add the missing features in the base libraries or to improve the existing<br>
> QGIS providers if the problems is in them, this will prevent duplication and<br>
> lower the maintenance efforts on the shoulders of QGIS developers.<br>
><br>
><br>
> --<br>
> Alessandro Pasotti<br>
> w3:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div></div></blockquote></div><br></div>