Bug report #13298
Shapefiles corrupting - objects and attributes becoming switched
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Digitising | ||
| Affected QGIS version: | 2.10.1 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | Yes | Copied to github as #: | 21356 |
Description
We've had recent experiences with one particular shapefile, where randomly some aspects of editing either object geometry or attributes is resulting in some line features dissapearing and the attributes of the one that is lost becoming attached to other objects in the file (and therefore their attributes lost).
On at least one occasion this behaviour has been related to using the split too (but we can't be sure it always is).
Have also seen some vertices of an object (that wasn't the one being edited) all of a sudden move to infinity (either south or east!) and no matter how far out we zoom, we never see the end of the line.
When attributes are getting mixed with other objects, it is often the record above or below in the dbf.
I have read some other forum issues detailing similar issues, but they often refer to the layer being edited by multiple people - this is definately NOT the case here. It was open by only one person.
We also never saw any "_packed" dbfs as others have reported.
History
#1
Updated by Saber Razmjooei almost 9 years ago
- Status changed from Open to Feedback
- Priority changed from High to Low
Is the file located on a network drive?
Is your file topologically correct? I have seen this happened in the past when there is a row in dbf and no geometry for the data.
#2
Updated by Jamie Portman almost 9 years ago
Yes the files were on a network drive.
Objects were topologically correct (no errors when running "check geometry validity").
The files were ONLY ever edited in QGIS, so if somehow the row in dbf & geometry were out of sync, then it could only have been QGIS that has somehow caused it...??
#3
Updated by Saber Razmjooei almost 9 years ago
Could you try on the local drive?
#4
Updated by Jamie Portman almost 9 years ago
It was a very random issue and we never got to the bottom of what was even causing it.
I did have another shapefile that when I used the split-line tool it went a little crazy (nodes moving to infinity) - but not so much the switching of attributes with geometry.
I can try it on local drive and see if the same thing happens...
#5
Updated by Jamie Portman almost 9 years ago
- File Test_DodgyRoad.zip added
- File BeforeSplit.JPG added
- File Split.JPG added
- File AfterSplit.JPG added
- File AfterSplit_ZoomOut.JPG added
I found the shapefile and object that was having ONE of the issues (not the attributes and objects getting switched) but doing insane corruption changes when cut with the 'Split Object' tool.
See screen grabs and shapefile example attached.
When the line is cut using the Split Object tool in v2.10 - the result is as per the screen shots - with vertices moving to infinity and the object becomes un-selectable.
Exactly the same process in v2.81 results in the line being split exactly as expected.
The line feature probably originated from a CAD DXF, however has been edited, cut, moved and changed in QGIS many times over a period of months. It was only recently when I cut the line using v2.10 that this issue occurred. Clearly whatever is causing the issue was most likely present all along, but some change in v2.10 is now causing very unexpected results.
Interesting, if I copy and paste the feature and move it, then sometimes the copied feature behaves normally and other times not...!
Certainly some similar behaviour issues as seen in the other file that had issues, but I have yet to be able to replicate the switching objects and attributes problem.
*Note. in the screenshots, the original feature is the one on the left. The right one is a copied feature.
#6
Updated by Jamie Portman almost 9 years ago
Opps - forgot to mention, the above tests were done with the file on the local drive.
#7
Updated by Saber Razmjooei over 8 years ago
- Status changed from Feedback to Open
#8
Updated by Harrissou Santanna over 8 years ago
I wonder why this issue is set to low priority while it causes data corruption.
#9
Updated by Jean-Pierre Vinadia over 8 years ago
- File Destructuration_données_table_attributaire.zip added
- File Screen_Shot.JPG added
I have quite the same problem with QGIS 2.12.
I work on a local drive.
This problem does not appears with the 2.8.3 version.
When I modify lignes (cut, copy/paste for exemple) and then (or before) rename the field (un champ de la table attributaire) the names of some objets move in an other object.
Some times, I can just realise that this the problem has apeared only when I register the modifications. So, I also think that it is a high priority because it can completly "destroy" the file.
(I apology for my english. I hope that you can understand me)
#10
Updated by Giovanni Manghi over 8 years ago
- Status changed from Open to Feedback
- Priority changed from Low to High
This seems really similar to #13741
can someone provide a clear sequence of steps to allow us replicate the issue in a consistent way?
#11
Updated by Jean-Pierre Vinadia over 8 years ago
- File fichier_destructuré.zip added
The sequence (cf the attached file)
I open "Boucle fichier origine"
Save as "boucle fichier modifié"
and then cut lines.
At this moment, The attributes move from one objetc to another. (see screenshot in my messaqge above)
This problem appears again this morning, working with another computer in an other office with QGIS 2.12 .
Unfortunately, i cannot repeat this disfonction on my own comuter yet.
It seams to appear in a random way.
The sequence this morinig. All done with Tablemanager
Open a file with 10 fields.
Delete 9 fields keeping only the field "NOM". Rename it in NAME and add fields (ID, LONGUEUR)
The name of the object appears not on the right object.
#12
Updated by Jean-Pierre Vinadia over 8 years ago
- File BUG_QGIS.zip added
The problem appaers again with an other file. With QGIS 2.12.0
It's really a very very big problem. Fortunately, I had a save of my work. But this makes me unconfortable while using QGIS. I'm yet afraid of the results of my manipulations.
Il just delete one column caled "TYPE_FORM" and the codes of my table has been totaly destructured.
So th original file is 'Balisage"
The corrupted file is Balisage BUG 04-12
#13
Updated by Harrissou Santanna over 8 years ago
Hi,
How do you delete the field: with "Table Manager" plugin or with the Core tool available in attribute table?
#14
Updated by Jean-Pierre Vinadia over 8 years ago
With Tablemanager.
#15
Updated by Giovanni Manghi over 8 years ago
Jean-Pierre Vinadia wrote:
The problem appaers again with an other file. With QGIS 2.12.0
It's really a very very big problem. Fortunately, I had a save of my work. But this makes me unconfortable while using QGIS. I'm yet afraid of the results of my manipulations.
Il just delete one column caled "TYPE_FORM" and the codes of my table has been totaly destructured.
So th original file is 'Balisage"
The corrupted file is Balisage BUG 04-12
I can't see any incongruence between the two table of attributes. I also tested by removing the "TYPE_FORM" field from 'Balisage' and got no corruption of data whatsoever. Anyway if you still get problems by removing fields with table manager (but not QGIS itself) then report the issue in the table manager bug tracker, as is a 3rd party plugin.
#16
Updated by Giovanni Manghi over 8 years ago
Jean-Pierre Vinadia wrote:
I have quite the same problem with QGIS 2.12.
I work on a local drive.
This problem does not appears with the 2.8.3 version.
When I modify lignes (cut, copy/paste for exemple) and then (or before) rename the field (un champ de la table attributaire) the names of some objets move in an other object.
Just tested again on master and can't replicate.
I think we still miss here a clear way (detailed steps) to replicate the issue.
#17
Updated by Giovanni Manghi over 8 years ago
Jamie Portman wrote:
I found the shapefile and object that was having ONE of the issues (not the attributes and objects getting switched) but doing insane corruption changes when cut with the 'Split Object' tool.
See screen grabs and shapefile example attached.
When the line is cut using the Split Object tool in v2.10 - the result is as per the screen shots - with vertices moving to infinity and the object becomes un-selectable.
Exactly the same process in v2.81 results in the line being split exactly as expected.
just tested on master and can't replicate this behavior.
Detailed steps or a screencast would help.
#18
Updated by Giovanni Manghi over 8 years ago
I also can't replicate the original issue in the description, the one about the mixing/switching attributes.
Please test again on QGIS master and report back.
#19
Updated by Jamie Portman over 8 years ago
I have tested the Split Object Tool issue (with lines going crazy when cut) in the latest nightly dev version and 2.12 - both versions appear to have fixed this issue. It didn't occur with every shapefile, but I found one that it was happening with and it still happens in 2.10 but not from 2.12 onwards :)
What is still happening in the latest nightly dev build (2.13) is deleted objects are not removed properly when saved. I deleted half the objects from a Shapefile, saved edits and closed. Re-open in QGIS and they do not appear, however, open the file in ArcGIS and they are all still there. If a 'save-as' of the Shapefile is done in 2.13, then they are properly removed when the file is opened in ArcGIS.
The mixing/switching of attributes was a VERY random problem with one particular file. We have not been able to replicate or reproduce the exact sequence of steps with any other file. I suspect it has something to do with these 'ghost' deleted features, as when you split a line it effectively deletes that object and creates two new ones. It only even seemed to happen after having done a split of a feature, but it often wasn't discovered until hours later when much more editing had been done, so we couldn't be sure.
#20
Updated by Giovanni Manghi over 8 years ago
What is still happening in the latest nightly dev build (2.13) is deleted objects are not removed properly when saved. I deleted half the objects from a Shapefile, saved edits and closed. Re-open in QGIS and they do not appear, however, open the file in ArcGIS and they are all still there. If a 'save-as' of the Shapefile is done in 2.13, then they are properly removed when the file is opened in ArcGIS.
this unfortunately is a known issue, that should be fixes in 2.14
The mixing/switching of attributes was a VERY random problem with one particular file. We have not been able to replicate or reproduce the exact sequence of steps with any other file. I suspect it has something to do with these 'ghost' deleted features, as when you split a line it effectively deletes that object and creates two new ones. It only even seemed to happen after having done a split of a feature, but it often wasn't discovered until hours later when much more editing had been done, so we couldn't be sure.
this probably is a consequence of the above.
Can we close this issue then, as fixed in 2.12/master?
#21
Updated by Jamie Portman over 8 years ago
I think so.
It can always be reopened if we ever see it again and can figure out a repeatable cause.
Thanks.
#22
Updated by Jürgen Fischer over 8 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed/implemented