<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- we HAD to use SQLITE and not spatialite, even though we wanted to use a<br>spatially enabled db. It turned out that init time to create a spatialite<br>with current provider was way too long, and having a default empty DB<br>storing more than 4Mo of SRS, functions and various metadata was not a good<br>idea for QGIS project file.</blockquote><div><div>True, there are ways to make this smaller, but if this is to be a GPKG a spatialite Database should be avoided</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Can anyone give us imputs if GPKG, relying on spatialite implementation could suffer from the same drawbacks?</blockquote><div>With a Spatialite connection it is very easy to create an empty pure GPKG Database (106.5 Kb) with:</div><div>SELECT gpkgCreateBaseTables();<br></div><div><br></div><div>It would contain only 3 SRS (-1,0 and 4326) in 'gpkg_spatial_ref_sys' with all of the other GPKG admin-tables (including 'gpkg_extensions') empty.</div><div><br></div><div>Mark Johnson, Berlin Germany</div><div><br></div><div> </div></div></div>