[Qgis-developer] Memory data provider persistence

[Chris Crook]

Hi Paolo

This is about saving the persisting the data in memory data provider layers, which by default is discarded when the project is closed (although the layer definition is in the project file, all the data is lost).  It is not related to fTools.  It is specific to the memory data provider. 

However having a common storage area for project related data does sound a very good idea.  At the moment the solution for the memory layers is leaning towards an Sqlite storage, say in a file called project.qgis.mldb.  However this could be held in a common sqlite database, provided we respect a table naming convention.  That would certainly make sense for users wanting to move projects around.

Is that the sort of thing you are thinking of?

Cheers
Chris

-----Original Message-----
From: Paolo Cavallini [mailto:cavallini at faunalia.it] 
Sent: Thursday, 26 July 2012 5:29 p.m.
To: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Memory data provider persistence

Il 26/07/2012 06:31, Chris Crook ha scritto:
> So what I'm considering is rebuilding the plugin to read and write the memory layer data into a single file, say project.qgis.mldata, instead of the current multiple gml files.  
>
> Thoughts?
Hi Chris,
please consider that much the same problem applies to other plugins, especially Sextante and GDALTools. Now that we are going to have a Save as... facility also for rasters, this could also be included.
So a solution designed only for fTools seems suboptimal.
All the best.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario


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.