Bug #6075
Memory layer saver adds fid columns under QGIS 1.8
| Status: | In Progress | Start Date: | 07/20/2012 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assigned to: |  Chris Crook |
% Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Patch supplied: | No |
Description
With qgis 1.8, each time a project is saved, reopening project shows memory memory layer with an added "fid" field.
I guess memory provider has changed since it now asks to give SCR on creation.
Saving a second time , and reopening project adds a second fid field.
This ID is filled with "myProjectName_"+uniqueIDinProject.
I couldn't add more than 2 fid fields.
I understand one fid can be mandatory for editing purposes (is it really) . We should force it in new memory layer plugin and explain thoses rules to dev's. FID shouldn't be added twice, or even shouldn't be shown in QGIS like oid's for postgis.
- Sometimes, memory layer gets empty after project save. All work is lost. I couldn't' reproduce exact conditions for this bug, but it seems to be a blocker .
History
Updated by Chris Crook 10 months ago
I think there are three issues here:
1) Display of feature ids for memory layers. This is a change in the behaviour of the memory layer with the QGIS version, nothing to do with saving or restoring the feature. I haven't looked at the memory layer code yet to see why this has changed.
2) Issue with the FID being duplicated when the project is reloaded. This seems to be an issue with the ogr GML driver. I've done some investigation - it appears to relate to the 1.9.x? version of GDAL - certainly 1.9.1. One option to get around this in the meantime replace the GML format saved files with a spatialite database. This appeals to me, and would make the project directory much cleaner, though when I first proposed the plugin some of the devs were strongly in favour of a more "open" format. So I may make this an option.
3) Sometimes failing to save the layers. I haven't ever experienced this, or had any other feedback on it, so there is nothing I can do about it till there is a repeatable test case... or at least some clue as to when an why it is happening.
Updated by Chris Crook 10 months ago
- Status changed from New to In Progress
- Priority changed from Blocker to High
Updated by Chris Crook 10 months ago
I've released a new version of the MemoryLayerSaver which ignores the first attribute if it is called "fid". Not a good solution - a workaround pending a better solution, still a work in progress.
I've raised a ticket on gdal for the GML driver issue: http://trac.osgeo.org/gdal/ticket/4754
Also see discussion thread on dev list: http://lists.osgeo.org/pipermail/qgis-developer/2012-July/021156.html
Updated by regis Haubourg 10 months ago
Hi,
I tested your new version, that workaround works well for me.
Still a user who opens directly gml with OGR will see that FID field. Spatialite solution seems to be the right solution for me.
Updated by regis Haubourg 10 months ago
- File memlayer_1.0_before_save.jpg added
- File memlayer_1.0_after_save.jpg added
I made some further tests..
something wrong with field's ids:
Your plugin's patch destroys fid field if exists, but on opening, field #0 is not shown any more. See attached pictures.
This breaks any advanced labeling parameters. Advanced label fields are stored as dataDefinedProperties, which identifies fields with their order. Ex: <property key="labeling/dataDefinedProperty7" value="14"/>
Any idea why?
Updated by Chris Crook 10 months ago
I can work around the disappearance of field 0 - this comes from deleting the fid field after the data is loaded. With a bit more work I can avoid loading the field in the first place.
However I'll postpone this till I've finished looking at other storage options..