Hi I also think as generally policy supporting OGR is a better way to go where possible.
Regards Tim > On 27 Feb 2018, at 23:29, Régis Haubourg <[email protected]> wrote: > > Thanks Alessandro and Nyall, > 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? > Thoughts? > Régis > > 2018-02-27 22:05 GMT+01:00 Nyall Dawson <[email protected] > <mailto:[email protected]>>: > On 28 February 2018 at 06:40, Alessandro Pasotti <[email protected] > <mailto:[email protected]>> wrote: > > On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> > > >> > On 27/02/2018 11:12, Mark Johnson wrote: > >> >>>> that we get rid of the current provider and rely on GDAL only. > >> >> > >> >> With the 'current provider' I assume you mean the Spatialite-Provider. > >> >> > >> >> Please remember that the Spatialite-Provider was never designed to > >> >> support GeoPackage. > >> >> > >> >> Please also remember that Gdal/Ogr does not support all aspects of > >> >> Spatialite > >> >> - writable SpatialViews are not supported > >> >> > >> >> The present QgsOgrProvider does not support Spatialite-Tables with more > >> >> than 1 geometry properly. > >> > > >> > Would it be possible to add these to the QgsOgrProvider, or are there > >> > some limitations ? > >> > >> Hi Hugo > >> > >> Some technical opinion are available in related PR done by Mark to > >> propose a new Spatialite provider. > >> The general opinion is to check before if it make sense to remove > >> spatialite limitations in the gdal provider to sqlite. > >> There are also opinon that the PR is actually not so simple to review, > >> for the complexity and extension. Oslandia can do it if apport more to > >> his business. > >> > >> IMHO I can't see any problem to merge it after review and have a new > >> or parallel spatialite provicer. > >> > > > > Well, I do: I think that unless there is an overwhelming technical reason to > > take a different route, QGIS should not create alternative providers where > > OGR/GDAL can do the job. > > +1. > > I strongly believe it would be a dangerous mistake for the QGIS > project to invest further development time and maintenance burden by > extending the spatialite provider, and I've made that view clear on > every discussion related to the spatialite provider over the 3.0 > development cycle. > > > The reason is both in how open source works: building wonderful applications > > on top of wonderful libraries (GDAL/OGR in this case) and in how we should > > avoid to enlarge the code base without a valid reason. > > > > The right approach in this particular case is IMHO to work with OGR/GDAL to > > add the missing features in the base libraries or to improve the existing > > QGIS providers if the problems is in them, this will prevent duplication and > > lower the maintenance efforts on the shoulders of QGIS developers. > > Alessandro has summed up my thoughts exactly. > > Nyall > _______________________________________________ > QGIS-Developer mailing list > [email protected] <mailto:[email protected]> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > <https://lists.osgeo.org/mailman/listinfo/qgis-developer> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > <https://lists.osgeo.org/mailman/listinfo/qgis-developer> > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer — Tim Sutton Co-founder: Kartoza Project chair: QGIS.org Visit http://kartoza.com <http://kartoza.com/> to find out about open source: Desktop GIS programming services Geospatial web development GIS Training Consulting Services Skype: timlinux IRC: timlinux on #qgis at freenode.net
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
