<div dir="ltr"><div><div><div>Thanks Alessandro and Nyall, <br></div>that said, it means that two reviewers are probably not found of having those PR integrated as is. Our community is based on consensus I think, Could we raise that topic up to the PSC level?<br></div>Thoughts?<br></div>Régis<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-27 22:05 GMT+01:00 Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 28 February 2018 at 06: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>
</div></div>+1.<br>
<br>
I strongly believe it would be a dangerous mistake for the QGIS<br>
project to invest further development time and maintenance burden by<br>
extending the spatialite provider, and I've made that view clear on<br>
every discussion related to the spatialite provider over the 3.0<br>
development cycle.<br>
<span class=""><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>
</span>Alessandro has summed up my thoughts exactly.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><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>