[Qgis-developer] Memory data provider persistence

[Chris Crook]

... And still further thoughts on this ...

Basically I think there are two issues here.  One is to do with the project file, and the exciting option of using a zipped project file with multiple documents in it, including the project XML file, and whatever resources it uses. 

The other is storing and reloading memory provider data, so that the reloaded project is represents what was saved.  

What I've come to realize is that these are independent issues.  I agree with Martin that embedding in the XML file is a bad idea, as the data could become too big to reside comfortably there. Reloading the memory provider data requires that the data exists in a well known location (eg projectFile + ".data") from which it is reloaded.  If the project is a zip file project, then this is included in the project.  If the project is an XML project, then it sits alongside it.

Either way, the implementation of the memory provider persistance is independent of the zipping or otherwise of the project file.

>From my point of view this is good, as I need the memory provider, whereas the zip project file is a nice to have. 

So, for my requirement for memory provider persistance, the only real question is what is the right way to do it.  Although Martin had suggested a spatialite database, my leaning is towards a simple QDataStream.  A simple implementation could be (in crude pseudo code)

Qstring header("Qgis data file");
Int version = 1;
stream << header << version;

Foreach memory_provider
  if provider < persist
      stream << layer_id
      stream << attribute_count
      foreach attribute
         stream << attribute_definition
      stream << feature_count
      foreach feature
         stream << feature

This could readily be reloaded after the XML project file is read.

Because it is processed sequentially it would sit comfortably in a ZIP file and be sequentially read from it without needing to be extracted and then processed (as a spatialite database would need to be).  It is portable between OS etc.

If the user actually wants a spatialite database, or any other format, then they can save the layer to that.

How does this sound to people?

Cheers
Chris

-----Original Message-----
From: Martin Dobias [mailto:wonder.sk at gmail.com] 
Sent: Sunday, 5 December 2010 6:08 a.m.
To: Chris Crook
Cc: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Memory data provider persistence

Hi Chris

On Sat, Dec 4, 2010 at 3:35 AM, Chris Crook <ccrook at linz.govt.nz> wrote:
> 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.

This would be also a solution, though I would prefer the former approach with a ZIP file containing the project XML and other files.
The advantages I see here is that it would be simpler to store various other types of data - with the project we could store also raster layers, SVGs for symbols or any other blobs. Loading and saving these data from/to sqlite database would be a bit cumbersome compared to an archive.

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