Re: [Qgis-developer] Memory data provider persistence
I don't know much about the memory layer handling - but here are some thoughts: I think Jürgen's idea makes a lot of sense: keep in-memory spatialite database, and save/restore when the project is saved/opened. And the user can export the layer to a preferred format if he/she wishes. Perhaps this could be added to qgis core, as a plugin or c++ ? I also think having spatialite as a required dependency is not a problem. Etienne On Thu, Jul 26, 2012 at 1:51 AM, Jürgen E. j...@norbit.de wrote: Hi, On Thu, 26. Jul 2012 at 16:31:46 +1200, Chris Crook wrote: Thoughts? I didn't really follow this thread. But the subject made me wonder if anybody ever mentioned/explored sqlite/spatialite in-memory databases[1] and their backup facility[2]? Would that be an option? Maybe even as replacement for the memory provider itself. Jürgen [1] http://www.sqlite.org/inmemorydb.html [2] http://www.sqlite.org/backup.html -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
We are designing the raster save as in a way that could be re-used elsewhere, perhaps vector saving could follow the same route - although not much (nothing) can be shared between the vector and raster dialogs. Etienne On Thu, Jul 26, 2012 at 2:29 AM, Paolo Cavallini cavall...@faunalia.it wrote: 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi Even Thanks for the suggestion and code examples - very helpful. I haven't followed up on this yet partly because this has prompted me to look at other storage formats for the data (something I'd been putting off). If I understand the GML driver documentation properly then I would have to manage the possibility of the user having a field called FID, as after I've saved the data, then reloaded with GMS_EXPOSE_FID set to NO, that field will be lost? As you suggest, renaming the fields before saving and then after reloading would fix handle this. Cheers Chris -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Thursday, 26 July 2012 6:47 a.m. To: qgis-developer@lists.osgeo.org Cc: Chris Crook; haubourg Subject: Re: [Qgis-developer] Memory data provider persistence Le mercredi 25 juillet 2012 20:03:16, Chris Crook a écrit : 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 :-) Chris, did you try setting GML_EXPOSE_FID to NO before opening the GML as we discussed on the GDAL trac system ? This should fix your issue without much code, basically calling CPLSetConfigOption(GML_EXPOSE_FID, NO) (or gdal.SetConfigOption(GML_EXPOSE_FID, NO) if you're coding in Python) before doing the OGROpen() call with the GML file. Actually, to avoid polluting other portions of code, you should save the original value and restore it afterwards, so : in C/C++ : char* pszOldVal = CPLGetConfigOption(GML_EXPOSE_FID) ? strdup(CPLGetConfigOption(GML_EXPOSE_FID)) : NULL; CPLSetConfigOption(GML_EXPOSE_FID, NO); OGRDataSource hDS = OGROpen(); CPLSetConfigOption(GML_EXPOSE_FID, pszOldVal); free(pszOldVal); in Python : old_val = gdal.GetConfigOption(GML_EXPOSE_FID) gdal.SetConfigOption(GML_EXPOSE_FID, NO) ds = ogr.Open() gdal.SetConfigOption(GML_EXPOSE_FID,old_val) And to avoid confusion, yes, you should also avoid that a user creates a 'FID' field. Cheers Chris From: haubourg [regis.haubo...@eau-adour-garonne.fr] Sent: 23 July 2012 20:58 To: qgis-developer@lists.osgeo.org 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-t p410 8012p4989995.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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer 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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Le jeudi 26 juillet 2012 21:41:57, Chris Crook a écrit : Hi Even Thanks for the suggestion and code examples - very helpful. I haven't followed up on this yet partly because this has prompted me to look at other storage formats for the data (something I'd been putting off). If I understand the GML driver documentation properly then I would have to manage the possibility of the user having a field called FID, as after I've saved the data, then reloaded with GMS_EXPOSE_FID set to NO, that field will be lost? If a user creates a 'fid' field, then that one will be used to set the fid attribute of the element. It will not be lost strictly speaking, but indeed if GML_EXPOSE_FID is set to NO, then it will not be visible. As you suggest, renaming the fields before saving and then after reloading would fix handle this. Not sure to understand you here : are you speaking about the mechanism for saving the old value of GML_EXPOSE_FID, setting GML_EXPOSE_FID=OLD, calling OGROpen() and restoring the original value of GML_EXPOSE_FID ? If so, this will not change anything about the behaviour with a user field called 'fid'. The intention here was not to interfere with other parts of QGIS that might manipulate GML files. For example, if a user opens a GML file through Add Vector Layer, he might want to see the fid reported. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Good points. I'm thinking perhaps the solution is to use Sqlite/spatialite (don't get me wrong - I like and use spatialite a lot). But perhaps use the python spatialite driver directly, rather than the QgsVectorFileWriter class as I am currently doing, as I cannot see any OGR options for writing multiple layers to a single sqlite db. I have a version working using the QDataStream, which goes well .. It shouldn't be too hard to modify that to use spatialite. You also mentioned losing data completely .. Is is possible that this was data that hadn't been saved before QGIS was closed (ie you were still in editing mode). I think this may be a QGIS bug in 1.8. On ubuntu I am finding that QGIS does not prompt for for uncommitted edits. I'm sure that it used to do that.. Cheers Chris -Original Message- From: haubourg [mailto:regis.haubo...@eau-adour-garonne.fr] Sent: Thursday, 26 July 2012 7:55 p.m. To: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence Having a specific memory storage have pros and cons that you explained very well Chris. From a user point of view, one drawback is that if something goes wrong in memory layer loading whe project opens, or on memory layer save, data is lost. So User will for sure ask for a Add memory layer provider.. because they will try to reopen that dataset they see with their project. That's why I prefer SQLlite, already easy to open. It stores vector or raster, is compact, no install... BUT, we will be dependent of that tool and associated libraries, that's true. My bet is that Spatialite will be a MANDATORY tool for people who don't have postgis access or skills. One simple argument: it store long field names, and is fast. So QGIS should stick close to spatialite as much as it does for postgis. If we all agree on that roadmap, it would not be so risquy to choose spatialite .. Hope this helps.. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-persistence-tp4108012p4990975.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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Le jeudi 26 juillet 2012 22:52:47, Chris Crook a écrit : Hi Even Sorry .. lost wasn't quite correct. The point is that my code for saving some users data and then reloading needs to take account of whether they have a field called fid or not if I want the list of fields unchanged after saving and reloading the data. Either I have to record somewhere that the fid field is real (ie was in the original data set), and set the GML_EXPOSE_FID accordingly so that it appears in the reloaded data, or alternatively rename the users fields an a reversible way before I save the data so that none of the saved fields can be called fid (eg prefix all fields with u_ for example), and set GML_EXPOSE_FID to NO. At least that is my understanding of the way the driver works now? Well, you could do it, but I think you're infliciting yourself too much pain, but it's up to you as you're the coder ;-) Personnaly, I'd just prevent the user from creating a field called fid, saying it is a reserved name. But your solutions would certainly work. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
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 [regis.haubo...@eau-adour-garonne.fr] Sent: 23 July 2012 20:58 To: qgis-developer@lists.osgeo.org 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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
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; qgis-developer@lists.osgeo.org 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 [regis.haubo...@eau-adour-garonne.fr] Sent: 23 July 2012 20:58 To: qgis-developer@lists.osgeo.org 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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi, On Thu, 26. Jul 2012 at 16:31:46 +1200, Chris Crook wrote: Thoughts? I didn't really follow this thread. But the subject made me wonder if anybody ever mentioned/explored sqlite/spatialite in-memory databases[1] and their backup facility[2]? Would that be an option? Maybe even as replacement for the memory provider itself. Jürgen [1] http://www.sqlite.org/inmemorydb.html [2] http://www.sqlite.org/backup.html -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi I think the change in behaviour is due to the change in the gdal 1.9 implementation of the GML driver, which generates the fid field when the layer is reloaded. I am looking at a fix that basically removes the field after it is reloaded. Not an ideal solution (especially if you want a field called fid). On you other points on the memory layer saving, it may be worth reviewing the earlier discussions about the memory layer saver. http://lists.osgeo.org/pipermail/qgis-developer/2010-December/011876.html I have a couple of times proposed that memory layers get saved alongside the project or within the project file. Inside the project file is not a good idea - it could easily get too big. So the main question for the ideal solution is how to store the information. I am using the GML format as a preferrred open format (preferred in this case based on responese on the qgis dev list). I'm inclined to modify this to a format that uses a single file for all the layers as a cleaner implementation from the users perspective (eg if the project file is test.qgs then the persisted data is in test.qgs.db, or something like that). The format could be spatialite perhaps, or a zip file of the gml files? It would also get rid of the horrible long file names. I see in your bug post that you have found that sometimes the layers don't get saved at all. I haven't experienced this, but I did notice that if you start editing a layer, add some features, and then quit qgis without saving the edits, then there is no prompt for saving the edits. If the edits don't get saved then the memory saver plugin doesn't flag the project as dirty, and so the changes don't get saved. Could this match your example? Cheers Chris Crook -Original Message- From: haubourg [mailto:regis.haubo...@eau-adour-garonne.fr] Sent: Saturday, 21 July 2012 1:55 a.m. To: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence Hi all, one up for this topic. Since QGIS 1.8, memory layer saver is not working the same way as in 1.7.4. I raised a tickets here http://hub.qgis.org/issues/6075 http://hub.qgis.org/issues/6075 , but I think something changed in memory layer provider or OGR GML provider, and it maybe isn't a plugin issue: In fact, FID field was previously hidden to end user in QGIS but was present in GML. It was filled with F+id . It now is filled with projectName.+id. FID field is now shown to end user whic alterates table structure when saving. Reopening project, saving and reoping a second time add a second FID field. Anyone has an idea of what's going on ? BTW *I'am really interested to have a stable way of saving memory layers along with project.Anyone still working on it ? Having it part of the Core would be great too. I am ready to sponsor it since it. * What solution should we keep? gml+xsd along with project? A dialog asking what memory layers to save, and explaining what are thoses gml and xsd files would be nice too. I have seen users cleaning up those messy files since they did not understand what they were.. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-persistence-tp4108012p4989667.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 i...@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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi all, one up for this topic. Since QGIS 1.8, memory layer saver is not working the same way as in 1.7.4. I raised a tickets here http://hub.qgis.org/issues/6075 http://hub.qgis.org/issues/6075 , but I think something changed in memory layer provider or OGR GML provider, and it maybe isn't a plugin issue: In fact, FID field was previously hidden to end user in QGIS but was present in GML. It was filled with F+id . It now is filled with projectName.+id. FID field is now shown to end user whic alterates table structure when saving. Reopening project, saving and reoping a second time add a second FID field. Anyone has an idea of what's going on ? BTW *I'am really interested to have a stable way of saving memory layers along with project.Anyone still working on it ? Having it part of the Core would be great too. I am ready to sponsor it since it. * What solution should we keep? gml+xsd along with project? A dialog asking what memory layers to save, and explaining what are thoses gml and xsd files would be nice too. I have seen users cleaning up those messy files since they did not understand what they were.. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-persistence-tp4108012p4989667.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
On Mon, Dec 6, 2010 at 10:45 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: On Mon, Dec 6, 2010 at 2:04 AM, Chris Crook ccr...@linz.govt.nz wrote: 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? It sounds like you're just creating another spatial data format. Why not, on project exit, just go You have unsaved memory data layers - would you like them converted to [gml|shapefile|spatialite|whatever] and reloaded before saving/qutting or do you want to lose them forever?. I completely agree with Barry - to me it looks like a waste of time to invent a new data format - exclusively readable just by QGIS - and intended just to load/store some data from/to memory provider. Additionally, memory provider was thought to represent just temporary (nonpersistent) data - so asking the user to convert it to some other format when exiting seems reasonable to me. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
On Mon, Dec 6, 2010 at 2:04 AM, Chris Crook ccr...@linz.govt.nz wrote: 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? It sounds like you're just creating another spatial data format. Why not, on project exit, just go You have unsaved memory data layers - would you like them converted to [gml|shapefile|spatialite|whatever] and reloaded before saving/qutting or do you want to lose them forever?. Barry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
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. While the memory provider is intended for transient data, I think that it is a valid user requirement that it persist beyond the user session. In terms of the QDataStream suggestion, the idea is not to create a format, it is to persist the memory layer efficiently and transparently. I don't think that is the same thing. I guess that the requirements for the format are that it is reasonably compact and can be efficiently read from and written to a sequential data stream (to facilitate possible writing to a zip file or other compressed format in the future). Also it would be nice if it didn't generate a plethora of files. Any other format that meets that requirement would be good, and I certainly agree that using an open format is preferable. Other suggestions?? Cheers Chris From: Martin Dobias [wonder...@gmail.com] Sent: 06 December 2010 22:57 To: Barry Rowlingson Cc: Chris Crook; qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence On Mon, Dec 6, 2010 at 10:45 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: On Mon, Dec 6, 2010 at 2:04 AM, Chris Crook ccr...@linz.govt.nz wrote: 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? It sounds like you're just creating another spatial data format. Why not, on project exit, just go You have unsaved memory data layers - would you like them converted to [gml|shapefile|spatialite|whatever] and reloaded before saving/qutting or do you want to lose them forever?. I completely agree with Barry - to me it looks like a waste of time to invent a new data format - exclusively readable just by QGIS - and intended just to load/store some data from/to memory provider. Additionally, memory provider was thought to represent just temporary (nonpersistent) data - so asking the user to convert it to some other format when exiting seems reasonable to me. 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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
Hi Barry et al Good point about a plugin implementation .. I hadn't thought of that obvious option - definitely one to follow up on. It might still need a few tweaks in terms of Qgis. The QgisInterface has a projectRead() signal that could be used to trigger reloading the data, but I don't see a projectSaved() signal to trigger writing. Easy to add that though, and probably generally useful. Do you know of an alternative signal I could use to trigger writing? Given that there is a signal to hook in to this is, as you say, a piece of cake. I'm kicking myself for not having thought of this months ago!! In terms of file location my preference would be something directly related to the project file .. That is obviously easy. And shapefile is not my choice, just because of the messy bunch of files it creates and having so many of them and because the DBF format is limiting and pretty scungy! But that is personal preference I guess. Brilliant .. Cheers Chris -Original Message- From: b.rowling...@googlemail.com [mailto:b.rowling...@googlemail.com] On Behalf Of Barry Rowlingson Sent: Tuesday, 7 December 2010 7:40 a.m. To: Chris Crook Cc: Martin Dobias; qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence On Mon, Dec 6, 2010 at 6:05 PM, Chris Crook ccr...@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 __ 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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
On Mon, Dec 6, 2010 at 7:12 PM, Chris Crook ccr...@linz.govt.nz wrote: Hi Barry et al Good point about a plugin implementation .. I hadn't thought of that obvious option - definitely one to follow up on. It might still need a few tweaks in terms of Qgis. The QgisInterface has a projectRead() signal that could be used to trigger reloading the data, but I don't see a projectSaved() signal to trigger writing. Easy to add that though, and probably generally useful. There's a projectWrite signal: http://www.qgis.org/api/classQgsProject.html#a935c811d84c51e908c73868be9b69c4 which seems to be emitted before the layers are saved, so if anything hooked into that wants to make changes it should be able to. Haven't tried, but will that do the job? Given that there is a signal to hook in to this is, as you say, a piece of cake. I'm kicking myself for not having thought of this months ago!! The only problem might be if the memory provider doesn't set the project as dirty when it changes itself. Otherwise users could do a 'quit', and then qgis quits without chance to save the project. In terms of file location my preference would be something directly related to the project file .. That is obviously easy. And shapefile is not my choice, just because of the messy bunch of files it creates and having so many of them and because the DBF format is limiting and pretty scungy! But that is personal preference I guess. Agreed! I've been saving things as GML lately. Barry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
Yes .. I got carried away and put up a patch implementing the projectWrite signal in the QgisInterface before I saw this alternative. Though in fact I do think that is makes sense to have a QgsInterface projectSaved() signal matching the projectRead(). And maybe a savingProject() that happens before it is saved. I forgot about needing to catch changes in the memory provider data to set the dirty state .. This was part of my original plan for implementing the memory provider data into the project file itself but I forgot it in my excitement about a plug in option. (The excitement is about being to do it now - I still think this really belongs in the core system). Maybe if I can trap an event relating to saving edits, then if the edited layer provider is a memory provider I can set the project state to dirty. And plugins will have to set the dirty state themselves (this may happen anyway, eg when the contour plugin generates a new contour layer adding the layer sets the state). This is getting a bit messy though! So maybe there is still some work required to provide the signals for changes to vector provider data. In fact the project does need to take ownership of the data. For it all to make sense it needs a projectDataDirty() flag. Bother! Chris -Original Message- From: b.rowling...@googlemail.com [mailto:b.rowling...@googlemail.com] On Behalf Of Barry Rowlingson Sent: Tuesday, 7 December 2010 12:21 p.m. To: Chris Crook Cc: Martin Dobias; qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence On Mon, Dec 6, 2010 at 7:12 PM, Chris Crook ccr...@linz.govt.nz wrote: Hi Barry et al Good point about a plugin implementation .. I hadn't thought of that obvious option - definitely one to follow up on. It might still need a few tweaks in terms of Qgis. The QgisInterface has a projectRead() signal that could be used to trigger reloading the data, but I don't see a projectSaved() signal to trigger writing. Easy to add that though, and probably generally useful. There's a projectWrite signal: http://www.qgis.org/api/classQgsProject.html#a935c811d84c51e908c73868be9b69c4 which seems to be emitted before the layers are saved, so if anything hooked into that wants to make changes it should be able to. Haven't tried, but will that do the job? Given that there is a signal to hook in to this is, as you say, a piece of cake. I'm kicking myself for not having thought of this months ago!! The only problem might be if the memory provider doesn't set the project as dirty when it changes itself. Otherwise users could do a 'quit', and then qgis quits without chance to save the project. In terms of file location my preference would be something directly related to the project file .. That is obviously easy. And shapefile is not my choice, just because of the messy bunch of files it creates and having so many of them and because the DBF format is limiting and pretty scungy! But that is personal preference I guess. Agreed! I've been saving things as GML lately. Barry __ 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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
... 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...@gmail.com] Sent: Sunday, 5 December 2010 6:08 a.m. To: Chris Crook Cc: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence Hi Chris On Sat, Dec 4, 2010 at 3:35 AM, Chris Crook ccr...@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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi Chris On Sat, Dec 4, 2010 at 3:35 AM, Chris Crook ccr...@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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
Yes, I can see that there definitely are advantages to a ZIP format from the point of view of accessing the contents from other programs or a command line interface. I think either would be as easy from within QGIS - an Sqlite blob can be used pretty much as a file stream so any arbitrary content could be embedded in the Sqlite database. I guess it depends whether you want to get at the spatial data more easily, by using the Sqlite option, or the other contents, by using the zip option. I think that you are right, that the zip option is probably more useful for a project file. And as you point out, it is an approach used by other software too. If we are going the zip route, I wonder if it would be a better idea to serialize the memory data to a QDataStream represented as a file in the zip archive, rather than as a spatialite database. The thought here is that it could then be read directly from the zip archive (as it would be read sequentially to reload), whereas an Sqlite database would probably need to be extracted to a temporary file to use. And the saved layer would remain a memory provided layer that way too, rather than an Sqlite layer, so the reinstated project would be a more accurate copy of the one originally saved. Cheers Chris From: Martin Dobias [wonder...@gmail.com] Sent: 05 December 2010 06:07 To: Chris Crook Cc: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence Hi Chris On Sat, Dec 4, 2010 at 3:35 AM, Chris Crook ccr...@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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Memory data provider persistence
Hi Martin and list readers Interesting idea! This would certainly achieve my main goal, which is to have the project reopen with the same information in as when I closed it. I agree that saving the the XML file could be cumbersome - even though these are only memory provider layers I guess they could get quite big. And very good point about loading from the DOM. 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. I don't see these options as exclusive. Look forward to comments, Chris From: Martin Dobias [wonder...@gmail.com] Sent: 03 December 2010 11:01 To: Chris Crook Cc: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] Memory data provider persistence Hi Chris On Mon, Nov 29, 2010 at 8:54 PM, Chris Crook ccr...@linz.govt.nz wrote: Hi All I'm looking for ideas/suggestions/comments on the memory data provider. A while ago I raised a ticket http://trac.osgeo.org/qgis/ticket/2487, the essence of which is that if you save and reload a project nothing should have changed, but if you have a layer supported by a memory data provider then its contents get lost. In the ticket I suggested that the user should be warned on saving, and the layers not included in the project file. That way at least you don't end up with empty layers. I'm now coming to a different point of view, which is that it would make much more sense to save the data for the memory provider into the project file. Having a possibility to save the data into a project would be a nice feature. However I think that saving the features directly into the XML project file wouldn't scale well with the amount of data. It can work well for small datasets, though I'm afraid that it will fail with a lot of data. One reason is that the project file would get pretty big due the verbosity of XML, another problem would be with the memory footprint and parsing speed - we're using DOM. I have started to think about a more radical step: to allow the projects to be not only XML files, but additionally they could be e.g. ZIP files with project XML file inside and optionally some more files. AFAIK OpenDocument format (used in OpenOffice) does this too. Internally QGIS could ask the user and convert his data from memory provider (or any other provider) to e.g. spatialite database that would be included in that project ZIP file. This would involve the following changes: - implement reading and writing of compressed project files (using zlib) - write a generic QgsVectorLayer - SpatiaLite export class (similar to QgsVectorFileWriter or an extension of it) - add support to read/write embedded layers This would also enable a nice feature to let QGIS pack all data into one (compressed) file and pass just that file around! What do you (and others) think of such solution? 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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory data provider persistence
Hi Chris On Mon, Nov 29, 2010 at 8:54 PM, Chris Crook ccr...@linz.govt.nz wrote: Hi All I'm looking for ideas/suggestions/comments on the memory data provider. A while ago I raised a ticket http://trac.osgeo.org/qgis/ticket/2487, the essence of which is that if you save and reload a project nothing should have changed, but if you have a layer supported by a memory data provider then its contents get lost. In the ticket I suggested that the user should be warned on saving, and the layers not included in the project file. That way at least you don't end up with empty layers. I'm now coming to a different point of view, which is that it would make much more sense to save the data for the memory provider into the project file. Having a possibility to save the data into a project would be a nice feature. However I think that saving the features directly into the XML project file wouldn't scale well with the amount of data. It can work well for small datasets, though I'm afraid that it will fail with a lot of data. One reason is that the project file would get pretty big due the verbosity of XML, another problem would be with the memory footprint and parsing speed - we're using DOM. I have started to think about a more radical step: to allow the projects to be not only XML files, but additionally they could be e.g. ZIP files with project XML file inside and optionally some more files. AFAIK OpenDocument format (used in OpenOffice) does this too. Internally QGIS could ask the user and convert his data from memory provider (or any other provider) to e.g. spatialite database that would be included in that project ZIP file. This would involve the following changes: - implement reading and writing of compressed project files (using zlib) - write a generic QgsVectorLayer - SpatiaLite export class (similar to QgsVectorFileWriter or an extension of it) - add support to read/write embedded layers This would also enable a nice feature to let QGIS pack all data into one (compressed) file and pass just that file around! What do you (and others) think of such solution? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Memory data provider persistence
Hi All I'm looking for ideas/suggestions/comments on the memory data provider. A while ago I raised a ticket http://trac.osgeo.org/qgis/ticket/2487, the essence of which is that if you save and reload a project nothing should have changed, but if you have a layer supported by a memory data provider then its contents get lost. In the ticket I suggested that the user should be warned on saving, and the layers not included in the project file. That way at least you don't end up with empty layers. I'm now coming to a different point of view, which is that it would make much more sense to save the data for the memory provider into the project file. Basically this would involve the following: 1) On saving a project, the data would be serialized into an element, probably in the map layer element in the project file. For example it could be a data... node. This could include the attribute definitions as well as each feature, or perhaps better the attribute definitions could be encoded into the datasourceUri. 2) On loading the data node would be read to repopulate the provider. Also useful, but not directly related to this, would be to enhance the layer Save as function so that when it is invoked on a memory layer the memory layer is replaced with the saved version, maybe as an option. In terms of implementation I think this could involve the following components: 1) Add virtual functions to the QgsDataProvider writeDataXML(QDomNode layerNode) and readDataXml( QDomNode layerNode) with default empty implementations. Call these functions in the QgsVectorLayer writeXml and readXml functions. 2) Add a signal dataSectionDirty() to the QgsDataProvider, so that edits to the data in a memory provider could render the project dirty. This signal would ultimately need to be linked to the project dirty() function. 2) Add serialization/deserialisation functions to QgsFeature, and QgsAttributeMap to read and write the data for a memory provider. There would be a question with this as to how much to structure the data for human consumption. Should the geometry be WKT or WKB? Should the attributes be simply serialized into a QDataStream and then encoded into XML, or should they be dumped more intelligently as structured XML elements. 3) Implement the readDataXml(), writeDataXml() functions in QgsMemoryProvider, and fire the dataSectionDirty() signal whenever the data is changed. I guess the main issue with this is that the project file would potentially get a lot larger when large memory data sets are added (eg Contour plugin). But I think that is better than silently losing the work held in a memory data provider. Any thoughts on these suggestions?? Thanks Chris __ 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 i...@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. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
