<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>