... 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:[email protected]]
Sent: Sunday, 5 December 2010 6:08 a.m.
To: Chris Crook
Cc: [email protected]
Subject: Re: [Qgis-developer] Memory data provider persistence
Hi Chris
On Sat, Dec 4, 2010 at 3:35 AM, Chris Crook <[email protected]> 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 [email protected]) 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
