<div dir="ltr"><div><div><div><div>Hi again, <br><br></div>two sidenotes:<br><br></div>- we called "auxiliary storage" the new QGIS 3 feature. I realize everyone uses "Ancillary storage" words. Should we rename that in the GUI? <br><br></div>- we HAD to use SQLITE and not spatialite, even though we wanted to use a spatially enabled db. It turned out that init time to create a spatialite with current provider was way too long, and having a default empty DB storing more than 4Mo of SRS, functions and various metadata was not a good idea for QGIS project file. Can anyone give us imputs if GPKG, relying on spatialite implementation could suffer from the same drawbacks? <br><br></div>And more largely on pushing hard on OWC standard, I think it is always a good idea that OpenSource is the leader on standards. <br>The feature could be exposed in "project" menu entry. "Save / Save As / Export As OWC" for instance<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-18 9:21 GMT+01:00 doublebyte <span dir="ltr"><<a href="mailto:joana@doublebyte.net" target="_blank">joana@doublebyte.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Just to elaborate a bit more some ideas about the geopackage as a format to<br>
support to ancillary storage:<br>
<br>
- From the mere technical point of view, geopackage is very convenient for<br>
storing QGIS projects. This is because we can actually store *everything*<br>
within the geopackage: project information, data, metadata, style and other<br>
data such as the information about labelling.<br>
<br>
- However, in my opinion, the added value of the OWC geopackage extension,<br>
which differentiates it from a common sqlite or spatialite db, is the fact<br>
that it relies on* OGC standards*. This is what enables us to port<br>
information to other GIS software which is no necessarily QGIS-aware.<br>
<br>
- Our proposal for the OWC geopackage extension is to keep it<br>
standards-based, which means that we could support use cases such as the<br>
ancilliary storage, if we would use mechanisms such as the tjs standard.<br>
Although the support to queries in the OWC context which Paul mentioned is<br>
still at the level of discussion, standards do evolve and I think that we<br>
(as QGIS community) could also get involved in this evolution, whenever we<br>
are pushing for generic and abstract mechanisms which could be reused by the<br>
whole geopackage community. So to wrap it up, the answer is "yes", we could<br>
support the ancillary storage, but we need to find out exactly how.<br>
<br>
- Another interesting feature which arises from this discussion, is the<br>
ability to support QGIS geopackage extensions in the core. Right now, the<br>
core reader is aware of the "standard" geopackage format (through OGR) and<br>
of the "qgis extension". If we implement it, it would also be aware of the<br>
"owc extension". But what if we could create a more abstract reader, which<br>
would look for extension tables and relate them to a certain "type" of<br>
plugin? This would allow people to implement reading support to different<br>
"flavours" of geopackages without much effort. I did not made a risk<br>
anaysis, so I am not sure if there are security (or other) issues associated<br>
to this, but I would love to hear your thoughts about this topic.<br>
<span class="im HOEnZb"><br>
                                                    Joana<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/QGIS-Developer-<wbr>f4099106.html</a><br>
</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>