Bug report #11989
Unexpected behaviour in QGIS Node Tool when adding vertex
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||Yes||Copied to github as #:||20195|
We have detect a strange behaviour with the Node Tool when we need to add a vertex to a polygon in a shapefile
The steps we have followed were those
1. Create a shapefile in QGIS.
2. Draw a simple polygon in the shapefile.
3. Activate the edit mode and click in the Node Tool
4. Double click in a line of the polygon to add a new vertex. The vertex seems to be correctly added
5. Move The new vertex
5. Save The changes in the Layer and finish editing mode
6. QGIS reports one feature
6. Open The Shape File in another program for example openjump. Openjump reports two features. We have tested in another programs and all of them reports two features.
Repack shapefiles when saving after deleting features
- QgsVectorDataProvider::dataChanged() will be emitted
- QgsVectorLayer::dataChanged() will be emitted
- Clears QgsVectorLayerCache
- Reloads the attribute table
- Clears the selection
Looking forward to people complaining about their lost selection...
#1 Updated by Juraj Komačka almost 5 years ago
- File test_11989.zip added
I have just followed your instructions with 2.6.1 (although edit mode described in step 3 must be activated before drawing polygon in step 2) and ended with attached shapefile.
ogrinfo test_11989.shp test_11989reports Feature Count: 1.
Could you, please, verify in Openjump? If only one feature will be reported, could you try upgrading from 2.6.0 to 2.6.1?
#2 Updated by Giovanni Manghi almost 5 years ago
- Category set to Vectors
- Priority changed from Normal to Severe/Regression
- Affected QGIS version changed from 2.6.0 to master
- Crashes QGIS or corrupts data changed from No to Yes
likely related to #10560
still true and the latest master and still a huge issue as it also affects Arc*, see for example this report
#3 Updated by Francisco Javier Garcia almost 5 years ago
The shapefile attached opened in my openjump only reports one feature, it seems correct, but the openjump "look" of giovanni if the same that my openjump reports with other test I've made. It seems that qgis duplicate the feature in some way when you move vertex.
In my tests If I save the opened shapefile in qgis in another file (export) it seems that the shapefile is "reindex" and you can open in another programs without any problems, but I think this is not the correct way of working.
ArcGIS have an external application to check if a shapefile is ok (shapechk.exe) (http://arcscripts.esri.com/details.asp?dbid=10806) and it reports that the shapefile saved in qgis have a problem in the index.
I don't know if I can provide more information about the problem.
#4 Updated by Giovanni Manghi almost 5 years ago
Francisco Javier Garcia wrote:
The shapefile attached opened in my openjump only reports one feature, it seems correct, but the openjump "look" of giovanni if the same that my openjump reports with other test I've made.
if the steps you described are not repeated exactly (add a vertex, move it) then the issue may not surface. Anyway is easy to replicate this issue with edited features, and overall is a pretty bad issue.
#7 Updated by Jürgen Fischer almost 5 years ago
Martin Dobias wrote:
This must be the same problem with not doing REPACK after editing (#11007 and #10560), resulting in a shapfile in semi-corrupt state - only when the layer is unloaded from QGIS or QGIS is closed, the REPACK happens.
hm, do we value the attribute editing and selection in shape layers more than their integrity? REPACK used to be run after every commit, fixing this and other things. But it changes the feature ids and therefore corrupts the current feature selection and interferes with open attribute tables.
#8 Updated by Martin Dobias almost 5 years ago
I was thinking along the same lines - to me preserving data integrity seems more important than having possibly temporary issues with selection and attribute table... (in theory we could try to keep a backup before repack, compare it after repack and issue a warning if an unwanted shift in IDs is detected).