<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi list, great to see so much enthusiasm for the suggested feature.<div class="">As you may know the GeoPackage standard itself by now already has quite a number of extensions. </div><div class=""><br class=""></div><div class=""><div class=""><a href="http://www.geopackage.org/extensions.html" class="">http://www.geopackage.org/extensions.html</a></div></div><div class=""><br class=""></div><div class="">It is to be expected that quite some of these extensions will also require a qgis plugin to access the extended data. Some of these extensions may act optimally if they are notified of a geopackage being opened (and are allowed to take over control of the thread). By allowing such a mechanism, developers may even write plugins that allow formats to be opened using qgis of which qgis before was not aware.</div><div class=""><br class=""></div><div class="">The suggested plugin falls in this category, the functionality to open OWC-geopackage is either moved to core (check if the geopackage contains a qgis-projects table else check if it contains an OWC table else … finally open as plain tables). Alternatively core could provide a mechanism that allows plugins to hook in the file-open event.</div><div class=""><br class=""></div><div class="">I have no clue of the impact of such a change, just wanted to raise the topic to hear your thoughts.</div><div class=""><br class=""></div><div class="">Related to the auxiliary storage discussion. This sounds like a cool feature for which I sure see a use case. OGC is working on a similar initiative called the “table joining service” (<a href="http://www.opengeospatial.org/standards/tjs/" class="">http://www.opengeospatial.org/standards/tjs/</a>) and I even recently read a thread about someone suggesting to put queries (with joins and filters) as a base for an OWS Context layer. However since auxiliary storage currently is very specific for QGIS, this will not be in the scope of our work, which is targeting moving full GIS projects between GIS environments by using standards. However I invite everyone to join in the initiative and create an extension that specifically targets this use case.</div><div class=""><br class=""></div><div class="">We have to consider that the QGIS project file has a lot of fancy things which will not be present anymore after being converted to an OWS Context. So when users are exporting their project the interface should guide them in selecting the best format for their use case.</div><div class=""><br class=""></div><div class="">Regards, Paul.</div><div class=""><br class=""></div></body></html>