[QGIS-Developer] Support to loading GIS projects from an extended OWC geopackage in the QGIS core

[Régis Haubourg]

Hi again,

two sidenotes:

- we called "auxiliary storage" the new QGIS 3 feature. I realize everyone
uses "Ancillary storage" words. Should we rename that in the GUI?

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

And more largely on pushing hard on OWC standard, I think it is always a
good idea that OpenSource is the leader on standards.
The feature could be exposed in "project" menu entry. "Save / Save As /
Export As OWC" for instance

2017-12-18 9:21 GMT+01:00 doublebyte <joana at doublebyte.net>:

> Hi,
>
> Just to elaborate a bit more some ideas about the geopackage as a format to
> support to ancillary storage:
>
> - From the mere technical point of view, geopackage is very convenient for
> storing QGIS projects. This is because we can actually store *everything*
> within the geopackage: project information, data, metadata, style and other
> data such as the information about labelling.
>
> - However, in my opinion, the added value of the OWC geopackage extension,
> which differentiates it from a common sqlite or spatialite db, is the fact
> that it relies on* OGC standards*. This is what enables us to port
> information to other GIS software which is no necessarily QGIS-aware.
>
> - Our proposal for the OWC geopackage extension is to keep it
> standards-based, which means that we could support use cases such as the
> ancilliary storage, if we would use mechanisms such as the tjs standard.
> Although the support to queries in the OWC context which Paul mentioned is
> still at the level of discussion, standards do evolve and I think that we
> (as QGIS community) could also get involved in this evolution, whenever we
> are pushing for generic and abstract mechanisms which could be reused by
> the
> whole geopackage community. So to wrap it up, the answer is "yes", we could
> support the ancillary storage, but we need to find out exactly how.
>
> - Another interesting feature which arises from this discussion, is the
> ability to support QGIS geopackage extensions in the core. Right now, the
> core reader is aware of the "standard" geopackage format (through OGR) and
> of the "qgis extension". If we implement it, it would also be aware of the
> "owc extension". But what if we could create a more abstract reader, which
> would look for extension tables and relate them to a certain "type" of
> plugin? This would allow people to implement reading support to different
> "flavours" of geopackages without much effort. I did not made a risk
> anaysis, so I am not sure if there are security (or other) issues
> associated
> to this, but I would love to hear your thoughts about this topic.
>
>                                                     Joana
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-
> f4099106.html
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171218/936c8b36/attachment.html>