Shapefiles corrupting - objects and attributes becoming switched #21356
Comments
|
Author Name: Saber Razmjooei (@saberraz) Is the file located on a network drive?
|
|
Author Name: Jamie Portman (Jamie Portman) Yes the files were on a network drive. Objects were topologically correct (no errors when running "check geometry validity"). |
|
Author Name: Saber Razmjooei (@saberraz) Could you try on the local drive? |
|
Author Name: Jamie Portman (Jamie Portman) It was a very random issue and we never got to the bottom of what was even causing it. |
|
Author Name: Jamie Portman (Jamie Portman) 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. 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.
|
|
Author Name: Jamie Portman (Jamie Portman) Opps - forgot to mention, the above tests were done with the file on the local drive. |
|
Author Name: Saber Razmjooei (@saberraz)
|
|
Author Name: Harrissou Santanna (@DelazJ) I wonder why this issue is set to low priority while it causes data corruption. |
|
Author Name: Jean-Pierre Vinadia (Jean-Pierre Vinadia) I have quite the same problem with QGIS 2.12. 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)
|
|
Author Name: Jean-Pierre Vinadia (Jean-Pierre Vinadia) The sequence (cf the attached file) This problem appears again this morning, working with another computer in an other office with QGIS 2.12 . The sequence this morinig. All done with Tablemanager
|
|
Author Name: Jean-Pierre Vinadia (Jean-Pierre Vinadia) 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.
|
|
Author Name: Harrissou Santanna (@DelazJ) Hi, |
|
Author Name: Jean-Pierre Vinadia (Jean-Pierre Vinadia) With Tablemanager. |
|
Author Name: Giovanni Manghi (@gioman) Jean-Pierre Vinadia wrote:
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. |
|
Author Name: Giovanni Manghi (@gioman) Jean-Pierre Vinadia wrote:
Just tested again on master and can't replicate. I think we still miss here a clear way (detailed steps) to replicate the issue. |
|
Author Name: Giovanni Manghi (@gioman) Jamie Portman wrote:
just tested on master and can't replicate this behavior. Detailed steps or a screencast would help. |
|
Author Name: Giovanni Manghi (@gioman) 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. |
|
Author Name: Jamie Portman (Jamie Portman) 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. |
|
Author Name: Giovanni Manghi (@gioman)
this unfortunately is a known issue, that should be fixes in 2.14
this probably is a consequence of the above. Can we close this issue then, as fixed in 2.12/master? |
|
Author Name: Jamie Portman (Jamie Portman) I think so. Thanks. |
|
Author Name: Jürgen Fischer (@jef-n)
|
qgib
added
Bug
Author Name: Jamie Portman (Jamie Portman)
Original Redmine Issue: 13298
Affected QGIS version: 2.10.1
Redmine category:digitising
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.
The text was updated successfully, but these errors were encountered: