[Qgis-developer] Memory data provider persistence

[Nathan Woodrow]

Hi all,

This is a very interesting idea indeed.  My personal preference would be a
zip file with the xml file inside for the project file, and other files for
the extra stuff eg memory layers, styles, images.

So:

MyProject.zqgs <- zip file with custom extension.
        |
        |> MyProject.qgs <- Project file
        |
        |> MyProectMemory.sqllte <- spatialite database
        |
        |> Other files, maybe some project specific qml files, images etc

My reason for using just a plan zip file with everything in it would be; it
makes it easier to get to the project file if needed; allows for as many
items as needed in the future; don't need anything special to view the
content.

As far as I am aware Steam, the gaming engine, does the same kind of thing
with its game files.

Just my 2 cents worth.

- Nathan

On Sat, Dec 4, 2010 at 1:35 PM, Chris Crook <ccrook at linz.govt.nz> wrote:

> Hi Martin and list readers
>
> Interesting idea!  This would certainly achieve my main goal, which is to
> have the project reopen with the same information in as when I closed it.
>
> I agree that saving the the XML file could be cumbersome - even though
> these are only memory provider layers I guess they could get quite big.  And
> very good point about loading from the DOM.
>
> Another way to achieve a similar result could be to embed the project file
> in the spatialite database?  That would make the memory provider data easier
> to use - basically it just becomes a spatialite provided layer.  The project
> itself becomes harder to manually edit, if you wanted to do so.  However it
> could easily be exported to a separate file if that is required.  And the
> whole thing could still be zipped if you wanted to.
>
> I don't see these options as exclusive.
>
> Look forward to comments,
> Chris
>
> ________________________________________
> From: Martin Dobias [wonder.sk at gmail.com]
> Sent: 03 December 2010 11:01
> To: Chris Crook
> Cc: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Memory data provider persistence
>
> Hi Chris
>
> On Mon, Nov 29, 2010 at 8:54 PM, Chris Crook <ccrook at linz.govt.nz> wrote:
> > Hi All
> >
> > I'm looking for ideas/suggestions/comments on the memory data provider.
> >
> > A while ago I raised a ticket http://trac.osgeo.org/qgis/ticket/2487,
> the essence of which is that if you save and reload a project nothing should
> have changed, but if you have a layer supported by a memory data provider
> then its contents get lost.
> >
> > In the ticket I suggested that the user should be warned on saving, and
> the layers not included in the project file.  That way at least you don't
> end up with empty layers.
> >
> > I'm now coming to a different point of view, which is that it would make
> much more sense to save the data for the memory provider into the project
> file.
>
> Having a possibility to save the data into a project would be a nice
> feature. However I think that saving the features directly into the
> XML project file wouldn't scale well with the amount of data. It can
> work well for small datasets, though I'm afraid that it will fail with
> a lot of data. One reason is that the project file would get pretty
> big due the verbosity of XML, another problem would be with the memory
> footprint and parsing speed - we're using DOM.
>
> I have started to think about a more radical step: to allow the
> projects to be not only XML files, but additionally they could be e.g.
> ZIP files with project XML file inside and optionally some more files.
> AFAIK OpenDocument format (used in OpenOffice) does this too.
> Internally QGIS could ask the user and convert his data from memory
> provider (or any other provider) to e.g. spatialite database that
> would be included in that project ZIP file.
>
> This would involve the following changes:
> - implement reading and writing of compressed project files (using zlib)
> - write a generic QgsVectorLayer -> SpatiaLite export class (similar
> to QgsVectorFileWriter or an extension of it)
> - add support to read/write "embedded" layers
>
> This would also enable a nice feature to let QGIS pack all data into
> one (compressed) file and pass just that file around!
>
> What do you (and others) think of such solution?
>
> Regards
> Martin
>
> ______________________________________________________________________________________________________
>
> This message contains information, which is confidential and may be subject
> to legal privilege.
> If you are not the intended recipient, you must not peruse, use,
> disseminate, distribute or copy this message.
> If you have received this message in error, please notify us immediately
> (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original
> message.
> LINZ accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ.
>
> Thank you.
>
> ______________________________________________________________________________________________________
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20101204/2d170c1d/attachment-0001.html