<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi</p>
<p>First, thanks for sharing your thoughts, Joana.</p>
<p>To make sure I understand the approach proposed here. It will
preserve any style information and labeling which can be converted
to SLD, but not other qgis specific ones (which I think is an
implication of the term "standard" which doesn't apply to the qgis
project file xml format)? In explicit having maximum
cross-compatibility while sacrificing some of the advanced QGIS
rendering possibilities.</p>
<p>Régis, I remember Even Rouault had some inputs how to create a
spatialite db without all this information (some flag on
creation). I would enjoy seeing the gpkg approach though (and
wonder why your message sounds like accessing it via spatialite is
a key requirement).<br>
</p>
<p>Cheers<br>
</p>
<p>Matthias<br>
</p>
<br>
<div class="moz-cite-prefix">On 12/18/2017 09:39 AM, Régis Haubourg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABgOYCc6Hq_zF+J-JVPhTR4-x2PPDoAA2n43G0ezW2cQ3odLhA@mail.gmail.com">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>