Hi again When I originally was proposing saving the memory layer (as a built in function of QGIS rather than as a plugin), I was thinking of streaming the data out and back using a QDataStream. It would have minimal overhead, unlike say converting to GML, or storing in an SQLite database. Also it would mean loading data into another format and then copying back into the memory layer, as is currently done, as it would just be read sequentially into the memory layer.
On the down side it would have no use other than for reloading the memory layer data. I got some feedback suggesting that this was not a good thing ... why was I creating another spatial data format. However I'm now wondering if that is a better way to go, since in addition to the minimal overhead, it also makes the plugin independent of potential changes in other components, such as the OGR GML driver in this case, which could change and break the functionality. Also it removes any concerns about the data being altered as it gets passed into another format and back again. The QDataStream is a versioned format, so it should be easy to ensure compatibility with future implementations of the Qt framework. If the user actually wants to use the data outside of QGIS, then they can save it the format they want from QGIS. The purpose of the memory layer persistence is to allow the user to close the project (possibly move it), open it again, and not lose their data - basically to be able to carry on working without having to worry whether or not their data is in memory layers or other forms. (This is how I think QGIS should behave by default). The plugin is not intended to save the data for other uses. Given that the default behaviour of QGIS (without the plugin), is to discard the data altogether, I think it is safe to assume that this is not seen as a requirement! 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? Chris -----Original Message----- From: Chris Crook Sent: Thursday, 26 July 2012 6:03 a.m. To: haubourg; [email protected] Subject: RE: [Qgis-developer] Memory data provider persistence Hi .. yes I don't like masking the FID field and I'm not thinking this is a long term solution, even before the problem in my implementation with the field index issue (which I think I will be able to fix). I'm looking at a couple of options over the next few days .. and open to any contributions, suggestions, code, etc :-) Cheers Chris ________________________________________ From: haubourg [[email protected]] Sent: 23 July 2012 20:58 To: [email protected] Subject: Re: [Qgis-developer] Memory data provider persistence Hi Chris, thanks for your feedback. I start thinking using a spatialite is a great idea. I prefer this than having rules to mask FID field. This can generate very hard-to-find bugs.. Having a complex Qgs zipfile containing either a spatialite DB or xml + data would be great but is a big evolution. IMHO, such a break should be kept for a major version change in QGIS (2.0?). Is that a work you are on ? Need contributors? -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-persistence-tp4108012p4989995.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. 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
