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 <[email protected] > <mailto:[email protected]>>: > > 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 > [email protected] <mailto:[email protected]> > 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
