Unexpected behaviour in QGIS Node Tool when adding vertex

[qgib]

Author Name: Francisco Javier Garcia (Francisco Javier Garcia)
Original Redmine Issue: 11989
Affected QGIS version: master
Redmine category:data_provider/ogr

---

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

6. Save The changes in the Layer and finish editing mode

7. QGIS reports one feature

8. 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 (Juraj Komačka)

---

Related issue(s): #17515 (relates)
Redmine related issue(s): 8822

---

[qgib]

Author Name: Juraj Komačka (Juraj Komačka)

---

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.

``` 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?

---

-  8302  was configured    as test_11989.zip 

---

- [test_11989.zip](https://issues.qgis.org/attachments/download/8302/test_11989.zip) (Juraj Komačka)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

likely related to #18967

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

---

• category_id was configured as Vectors
• priority_id was changed from Normal to Severe/Regression
• version was changed from 2.6.0 to master
• crashes_corrupts_data was changed from 0 to 1

[qgib]

Author Name: Francisco Javier Garcia (Francisco Javier Garcia)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

• category_id was changed from Vectors to Digitising

[qgib]

Author Name: Martin Dobias (@wonder-sk)

---

This must be the same problem with not doing REPACK after editing (#19349 and #18967), resulting in a shapfile in semi-corrupt state - only when the layer is unloaded from QGIS or QGIS is closed, the REPACK happens.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

Martin Dobias wrote:

This must be the same problem with not doing REPACK after editing (#19349 and #18967), 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.

[qgib]

Author Name: Martin Dobias (@wonder-sk)

---

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

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

• category_id was changed from Digitising to Data Provider/OGR

[qgib]

Author Name: Matthias Kuhn (@m-kuhn)

---

Fixed in changeset "7d7cdcd376c0d3fa60af1403a91e1e611b210174".

---

• status_id was changed from Open to Closed