[QGIS-Developer] Support to loading GIS projects from an extended OWC geopackage in the QGIS core
Régis Haubourg
regis.haubourg at gmail.com
Sun Dec 17 13:34:45 PST 2017
>
> Thanks for laying everything out so clearly Régis! One other thing I
> wondered about ancillary data is the ability to store images or other
> external resources linked to a layer - there was some discussion about how
> to manage this in Nødebo too….
>
> Regards
>
> Tim
>
Hi Tim,
I missed that discussion sorry. I don't see why we couldn't use the sqlite
DB as a blob container, as it is a supported type.
However, like in all electronic document storage stories, the cardinalities
will probaby not fit well with the current use of simple joined layers
where one layer as one joined auxiliary table.
Storing many pictures linked to one feature might require a "document"
table and a relation table between layers and documents.
All this reminds me of the QEP 79 "Document Management Systems" a lot!
Cheers
Régis
2017-12-16 23:11 GMT+01:00 Tim Sutton <tim at kartoza.com>:
> Hi
>
> On 15 Dec 2017, at 15:26, Régis Haubourg <regis.haubourg at gmail.com> wrote:
>
> Hi all,
>
> some years ago, we discussed of a new project file format able to store
> data and other ressources has been discussed.
>
> We finally had the opportunity to make one step forward when working on
> the auxiliary data storage stuff.
>
> What's the current status in QGIS 3:
>
> - we now have an optional format ".qgz" that is a zipped file
> - 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
> - when zip fil format is chosen, the qgd file is stored inside the qgz.
>
> 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.
>
> We also now have a container for storing SVG, color ramps, pictures or any
> additionnal ressource that should be shipped within the project.
>
> Now my opinion on the proposal about storing all inside a GPKG:
>
> - 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.
> - 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.
>
> 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.
>
>
> Thanks for laying everything out so clearly Régis! One other thing I
> wondered about ancillary data is the ability to store images or other
> external resources linked to a layer - there was some discussion about how
> to manage this in Nødebo too….
>
> Regards
>
> Tim
>
>
> Best regards !
> Régis
>
>
> Le 15 déc. 2017 10:16, "Richard Duivenvoorde" <rdmailings at duif.net> a
> écrit :
>
>> On 14-12-17 13:59, Alessandro Pasotti wrote:
>> > Hi Joana,
>> >
>> > I think this would be a great addition to QGIS.
>> >
>> > Big +1 from me, and thanks for the proposal.
>> >
>> >
>> >
>> > On Thu, Dec 14, 2017 at 1:49 PM, doublebyte <joana at doublebyte.net
>> > <mailto:joana at doublebyte.net>> wrote:
>> >
>> > Hello,
>> >
>> > Maybe some of you are aware of the "geopackage" plugin
>> > <https://eos.geocat.net/gitlab/joana.simoes/foss4g_gpkg/blo
>> b/master/foss4g_gpkg.pdf
>> > <https://eos.geocat.net/gitlab/joana.simoes/foss4g_gpkg/blo
>> b/master/foss4g_gpkg.pdf>>
>> > .The initial goal of this plugin was to enable users to save their
>> QGIS
>> > projects, including style and associated resources
>> > in a extended geopackage - the qgis geopackage extension
>> > <https://github.com/pka/qgpkg/blob/master/qgis_geopackage_
>> extension.md
>> > <https://github.com/pka/qgpkg/blob/master/qgis_geopackage_
>> extension.md>>
>> > -,
>> > and load it onto another QGIS installation; on this approach, the
>> > project is
>> > encoded as qgs, in a database table. Later the plugin was forked to
>> > support
>> > a different geopackage exension - the owc geopackage extension
>> > <https://github.com/pka/qgpkg/blob/master/owc_geopackage_
>> extension.md <https://github.com/pka/qgpkg/blob/master/owc_geopackage_ext
>> ension.md>>
>> > - ,
>> > which is standards-based; in this approach
>> > <https://www.geocat.net/announcing-the-extended-geopackage-
>> qgis-plugin/
>> > <https://www.geocat.net/announcing-the-extended-geopackage-
>> qgis-plugin/>>
>> > ,
>> > the style is encoded as OGC:SLD and the project as OGC:OWS context.
>> > The goal
>> > of this approach is to support the migration of GIS projects, as we
>> can
>> > implement this extension in any desktop or server side GIS (e.g.:
>> ArcGIS
>> > Desktop).
>> >
>> > The fork was merged in August this year, and the latest release of
>> the
>> > plugin <https://plugins.qgis.org/plugins/QgisGeopackage/
>> > <https://plugins.qgis.org/plugins/QgisGeopackage/>> already
>> contains
>> > both extensions, covering both use cases of porting QGIS projects
>> and
>> > migrating GIS projects. Recently, it was added support in the core
>> > to the
>> > "qgis geopackage extension"
>> > <https://github.com/qgis/QGIS/blob/master/src/providers/
>> ogr/qgsogrprovider.cpp#L762
>> > <https://github.com/qgis/QGIS/blob/master/src/providers/
>> ogr/qgsogrprovider.cpp#L762>>
>> > , in the qgsogrprovider class. This means that if a user loads a
>> > geopackage
>> > which was encoded using the "qgis geopackage extension", it will
>> > automatically load the QGIS project from it. We think that it makes
>> > sense to
>> > also add the "ows geopackage extension" to the core; in that case,
>> > users
>> > could load projects exported from other GIS software seamlessly,
>> without
>> > having to load the plugin. The mechanism would be very similar to
>> > what was
>> > already implemented for the "qgis geopackage extension".
>> >
>> > Before preparing any Pull Request, we would like to understand first
>> > what is
>> > the general feeling of the community about this feature; is this
>> > something
>> > which seems useful and interesting to add to the QGIS core? If yes,
>> > we would
>> > also appreciate any comments regarding any details the
>> implementation.
>> >
>> > Looking forward to hearing your feedback :-)
>>
>> Yes, please! I think there was an issue about not being able to load an
>> extended gpkg:
>>
>> https://issues.qgis.org/issues/17698
>>
>> so it looks like fixing a bug
>>
>> :-)
>>
>> R
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
>
>
> —
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171217/2481fc42/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171217/2481fc42/attachment-0001.jpg>
More information about the QGIS-Developer
mailing list