Bug report #11989

Unexpected behaviour in QGIS Node Tool when adding vertex

Added by Francisco Javier Garcia almost 10 years ago. Updated over 9 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Data Provider/OGR
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

Description

Hi

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.

Best regars

test_11989.zip (1.02 KB) Juraj Komačka, 2015-01-16 11:22 PM

Related issues

Related to QGIS Application - Bug report #8822: OGR: Repack in running session Closed 2013-10-11

Associated revisions

Revision 7d7cdcd3
Added by Matthias Kuhn over 9 years ago

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...

Fix #10560
Fix #11989
Refs #8317
Refs #8822
Refs #10483
Refs #11007
Refs #7540
Refs #11398
Refs #11296

History

#1 Updated by Juraj Komačka almost 10 years ago

Hi,

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_11989
reports 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 10 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

https://twitter.com/RyanMHorne/status/556472289915850753

#3 Updated by Francisco Javier Garcia almost 10 years ago

Hi

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 10 years ago

Francisco Javier Garcia wrote:

Hi

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.

#5 Updated by Jürgen Fischer almost 10 years ago

  • Category changed from Vectors to Digitising

#6 Updated by Martin Dobias almost 10 years ago

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.

#7 Updated by Jürgen Fischer almost 10 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 10 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).

#9 Updated by Jürgen Fischer almost 10 years ago

  • Category changed from Digitising to Data Provider/OGR

#10 Updated by Matthias Kuhn over 9 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF