[Qgis-developer] Memory data provider persistence
Barry Rowlingson
b.rowlingson at lancaster.ac.uk
Mon Dec 6 13:40:16 EST 2010
On Mon, Dec 6, 2010 at 6:05 PM, Chris Crook <ccrook at linz.govt.nz> wrote:
> Hi All
>
> Fair comment I guess. In fact Barry's suggestion is pretty much back at my original ticket on this issue. This had two components, one was the warning about memory provider layers, and the other was making it easier to save them (or more accurately, to replace the memory layer with the saved layer in the project). Ideally the legend would also have some sort of visual clue as to which layers were not yet saved.
>
> Nonetheless I do think there is value in having the memory provided data saved more or less transparently to the user. For example the contour plugin builds its contours in a memory layer. I don't want them to disappear when I save and reopen the project. Yet sometimes I want to save the project quickly without having to decide where and in what format I want bits of it saved. For example when I have to exit the train on the way to work!! I just want to be able to save the project and then start up later and carry on working.
So as long as the saving of memory layers is quick, you're happy? So
what about if it happened transparently that memory layers were saved
to /tmp/something in Shapefile format, and the location and format
were configurable from a settings dialog and saved (either per-project
or in user settings), and that .qgs files added the converted layers
into the project? Sounds like a piece of cake, meets the 'train
suddenly arriving at station' criterion (although in this country you
get an extra twenty minutes past the expected arrival time with
trains), and could possibly be implemented as a plugin. You may never
lose memory data provider data again...
I'm not sure serializing the object to binary is a good idea, you
will one day want to load it into another GIS... Standards are a good
thing, that's why there are so many of them.
Barry
More information about the Qgis-developer
mailing list