<div dir="ltr"><div dir="auto">Hi all, <br><br></div><div>some years ago, we discussed of a new project file format able to store data and other ressources has been discussed. <br><br></div><div>We finally had the opportunity to make one step forward when working on the auxiliary data storage stuff. <br><br></div><div>What's the current status in QGIS 3:<br><br></div><div>- we now have an optional format ".qgz" that is a zipped file<br></div><div>- the auxiliary data storage is a sqlite database ".qgd" storing additional informations joined to classical layers (for manual labeling purposes for instance). It is NOT a spatialite database that could be the container for spatial data<br></div><div>- when zip fil format is chosen, the qgd file is stored inside the qgz. <br><br></div><div>So, the path is opened to modify the offline editing tools or other equivalent features to store their local datasource (either gpkg or sqlite) inside the qgz too. <br><br></div><div>We also now have a container for storing SVG, color ramps, pictures or any additionnal ressource that should be shipped within the project. <br><br></div><div>Now my opinion on the proposal about storing all inside a GPKG:<br><br></div><div>- I think we should first have a native "packaging" format using native qgs file, to adress what offline editing, Qconsolidate, or QFieldSync use cases requires. <br></div><div>- The "interoperability" use case should be adressed only as an option, not a default solution, since SLD conversion (and things that don't stick to standards) will alter the project. <br><br></div><div>I am in favor of discussing all that after QGIS3 is out so that we keep focused on that, and then discuss that at the Madeyra hackfest. I'd be pleased to animate a workgroup to reach common agreement, guidelines, and find a plan for that.<br><br></div><div>Best regards !<br></div><div>Régis<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 15 déc. 2017 10:16, "Richard Duivenvoorde" <<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14-12-17 13:59, Alessandro Pasotti wrote:<br>
> Hi Joana,<br>
><br>
> I think this would be a great addition to QGIS.<br>
><br>
> Big +1 from me, and thanks for the proposal.<br>
><br>
><br>
><br>
> On Thu, Dec 14, 2017 at 1:49 PM, doublebyte <<a href="mailto:joana@doublebyte.net" target="_blank">joana@doublebyte.net</a><br>
> <mailto:<a href="mailto:joana@doublebyte.net" target="_blank">joana@doublebyte.net</a>>> wrote:<br>
><br>
> Hello,<br>
><br>
> Maybe some of you are aware of the "geopackage" plugin<br>
> <<a href="https://eos.geocat.net/gitlab/joana.simoes/foss4g_gpkg/blob/master/foss4g_gpkg.pdf" rel="noreferrer" target="_blank">https://eos.geocat.net/gitla<wbr>b/joana.simoes/foss4g_gpkg/<wbr>blob/master/foss4g_gpkg.pdf</a><br>
> <<a href="https://eos.geocat.net/gitlab/joana.simoes/foss4g_gpkg/blob/master/foss4g_gpkg.pdf" rel="noreferrer" target="_blank">https://eos.geocat.net/gitla<wbr>b/joana.simoes/foss4g_gpkg/<wbr>blob/master/foss4g_gpkg.pdf</a>>><br>
> .The initial goal of this plugin was to enable users to save their QGIS<br>
> projects, including style and associated resources<br>
> in a extended geopackage - the qgis geopackage extension<br>
> <<a href="https://github.com/pka/qgpkg/blob/master/qgis_geopackage_extension.md" rel="noreferrer" target="_blank">https://github.com/pka/<wbr>qgpkg/blob/master/qgis_<wbr>geopackage_extension.md</a><br>
> <<a href="https://github.com/pka/qgpkg/blob/master/qgis_geopackage_extension.md" rel="noreferrer" target="_blank">https://github.com/pka/<wbr>qgpkg/blob/master/qgis_<wbr>geopackage_extension.md</a>>> <br>
> -,<br>
> and load it onto another QGIS installation; on this approach, the<br>
> project is<br>
> encoded as qgs, in a database table. Later the plugin was forked to<br>
> support<br>
> a different geopackage exension - the owc geopackage extension<br>
> <<a href="https://github.com/pka/qgpkg/blob/master/owc_geopackage_extension.md" rel="noreferrer" target="_blank">https://github.com/pka/<wbr>qgpkg/blob/master/owc_<wbr>geopackage_extension.md</a> <<a href="https://github.com/pka/qgpkg/blob/master/owc_geopackage_extension.md" rel="noreferrer" target="_blank">https://github.com/pka/qgpkg/<wbr>blob/master/owc_geopackage_ext<wbr>ension.md</a>>> <br>
> - ,<br>
> which is standards-based; in this approach<br>
> <<a href="https://www.geocat.net/announcing-the-extended-geopackage-qgis-plugin/" rel="noreferrer" target="_blank">https://www.geocat.net/annou<wbr>ncing-the-extended-geopackage-<wbr>qgis-plugin/</a><br>
> <<a href="https://www.geocat.net/announcing-the-extended-geopackage-qgis-plugin/" rel="noreferrer" target="_blank">https://www.geocat.net/annou<wbr>ncing-the-extended-geopackage-<wbr>qgis-plugin/</a>>> <br>
> ,<br>
> the style is encoded as OGC:SLD and the project as OGC:OWS context.<br>
> The goal<br>
> of this approach is to support the migration of GIS projects, as we can<br>
> implement this extension in any desktop or server side GIS (e.g.: ArcGIS<br>
> Desktop).<br>
><br>
> The fork was merged in August this year, and the latest release of the<br>
> plugin <<a href="https://plugins.qgis.org/plugins/QgisGeopackage/" rel="noreferrer" target="_blank">https://plugins.qgis.org/plug<wbr>ins/QgisGeopackage/</a><br>
> <<a href="https://plugins.qgis.org/plugins/QgisGeopackage/" rel="noreferrer" target="_blank">https://plugins.qgis.org/plu<wbr>gins/QgisGeopackage/</a>>> already contains<br>
> both extensions, covering both use cases of porting QGIS projects and<br>
> migrating GIS projects. Recently, it was added support in the core<br>
> to the<br>
> "qgis geopackage extension"<br>
> <<a href="https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L762" rel="noreferrer" target="_blank">https://github.com/qgis/<wbr>QGIS/blob/master/src/<wbr>providers/ogr/qgsogrprovider.<wbr>cpp#L762</a><br>
> <<a href="https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L762" rel="noreferrer" target="_blank">https://github.com/qgis/<wbr>QGIS/blob/master/src/<wbr>providers/ogr/qgsogrprovider.<wbr>cpp#L762</a>>><br>
> , in the qgsogrprovider class. This means that if a user loads a<br>
> geopackage<br>
> which was encoded using the "qgis geopackage extension", it will<br>
> automatically load the QGIS project from it. We think that it makes<br>
> sense to<br>
> also add the "ows geopackage extension" to the core; in that case,<br>
> users<br>
> could load projects exported from other GIS software seamlessly, without<br>
> having to load the plugin. The mechanism would be very similar to<br>
> what was<br>
> already implemented for the "qgis geopackage extension".<br>
><br>
> Before preparing any Pull Request, we would like to understand first<br>
> what is<br>
> the general feeling of the community about this feature; is this<br>
> something<br>
> which seems useful and interesting to add to the QGIS core? If yes,<br>
> we would<br>
> also appreciate any comments regarding any details the implementation.<br>
><br>
> Looking forward to hearing your feedback :-)<br>
<br>
Yes, please! I think there was an issue about not being able to load an<br>
extended gpkg:<br>
<br>
<a href="https://issues.qgis.org/issues/17698" rel="noreferrer" target="_blank">https://issues.qgis.org/issues<wbr>/17698</a><br>
<br>
so it looks like fixing a bug<br>
<br>
:-)<br>
<br>
R<br>
<br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">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/mailma<wbr>n/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a></blockquote></div></div>
</div>