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

[Matthias Kuhn]

Hi

First, thanks for sharing your thoughts, Joana.

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.

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

Cheers

Matthias


On 12/18/2017 09:39 AM, Régis Haubourg wrote:
> 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
> <mailto: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
>     <http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html>
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>     Unsubscribe:
>     https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
>
>
>
> _______________________________________________
> 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/40f4a238/attachment-0001.html>