<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 18, 2017 at 12:23 PM, Régis Haubourg <span dir="ltr"><<a href="mailto:regis.haubourg@gmail.com" target="_blank">regis.haubourg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks for all your pointers. <br><br></div><div>Discussing with Paul Blottiere and Hugo Mercier, we can give some global aswers:<br><br></div><div>- We didn't think about GPKG, because in the end there was no need to spatial data. Please remember that more than 6 months ago, GPKG wasn't as promoted and tested than now. <br></div><div><br>- Changing the OGR SQLITE provider to GOKG OGR provider shouldn't be too much work. The hardest part was synchronizing ancillary data with source layer. <br><br></div><div>- Spatialite provider is absolutely not a requirement. We tried to use it and it appeared too messy concerning featureId's and Primary keys too. Init creation option were not exposed in API to be able to quickly create a small DB. More largely on spatialite provider, and seeing Luigi's pointer to current Spatialite Pull Request, we really think we should only use OGR and mutualize all efforts there to have a unique and robust provider. <br><br></div></div></blockquote><div><br></div><div>Sorry, I don't want to hijack the thread but I couldn't agree more on your last point!<br></div></div>I'm convinced that we should use OGR/GDAL whenever possible, and when it's not: try hard to contribute to OGR/GDAL to remove the blocker.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></div>