Bug report #18007

QGIS 3 Vector data corruption when Adding a Point Feature

Added by Calvin Hamilton about 6 years ago. Updated about 6 years ago.

Status:Closed
Priority:High
Assignee:Alessandro Pasotti
Category:Attribute table
Affected QGIS version:master Regression?:Yes
Operating System:Windows 7 Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed/implemented
Crashes QGIS or corrupts data:Yes Copied to github as #:25903

Description

Attached is a sample data set to illustrate the problem. This was broken off as a separate issue from #17878.

To create the issue load test.gpkg into QGIS. Open the Attribute Table. The attribute table should look something like 'attribute_table_before.jpg'. Now click on the "Toggle Editing" toolbar icon and then click on the "Add Point Feature" icon. Now click anywhere on the map canvas to add a feature. For 'label' I called it test and left 'latitude' and 'longitude' as NULL. The net results is that this new data is added to line 6 with 'Autogenerate' as the fid (which is probably now what it should do), but the big problem is that Row 1 data becomes corrupted in the fields 'latitude' and 'longitude'. It looks like these fields were truncated to two decimal places. Adding a new feature should not affect row 1 at all. See 'bad_data.jpg' for what happens.

test.gpkg - Test data (116 KB) Calvin Hamilton, 2018-01-30 09:14 PM

attribute_table_before.jpg - Original attribute table (48.1 KB) Calvin Hamilton, 2018-01-30 09:15 PM

bad_data.jpg - Resulting table corruption (54 KB) Calvin Hamilton, 2018-01-30 09:15 PM


Related issues

Related to QGIS Application - Bug report #17861: SQLite REAL numbers displayed as too many digits in Attri... Closed 2018-01-15

Associated revisions

Revision 1adc55f3
Added by Alessandro Pasotti about 6 years ago

[bugfix] Lower priority of range widget for doubles

This was the root cause of several critical bugs with
data corruption in the attribute table and forms:
SpinBox has a fixed number of decimal places, which
makes it not ideal for floating points because most
of the times it rounds the number changing it when
in edit mode even if the user has not really modified
the value by writing in the spin box or using the
controls.

So, the defult is now back to the line edit (which has
bugs in the validator, but that's another less
critical and separate issue).

Partially fixes #17861
Partially fixes #18007

History

#1 Updated by Alessandro Pasotti about 6 years ago

  • Related to Bug report #17861: SQLite REAL numbers displayed as too many digits in Attribute Table added

#2 Updated by Alessandro Pasotti about 6 years ago

  • Pull Request or Patch supplied changed from No to Yes
  • Assignee set to Alessandro Pasotti
  • Status changed from Open to In Progress

Thanks for filing this, the root of this issue and of others related issues as well is that the default widget for "double" is now the spinbox widget, that has a fixed number of decimal places .
After my recent commits, the number of decimal places can be set by the user in the widget field options, but by default it takes the precision as reported by the provider, which is most of the times 0 (pure nonsense for a double).

But, even if the precision can now be set to something higher than 2 (the old default), you'll always (well, almost) have rounding errors that will alter the original value even if you don't directly edit it.

So, IMHO the only way out is to go back to the plain old lineedit widget by default (like it was in 2.x). See my comments in https://github.com/qgis/QGIS/pull/6209 and the new PR:
https://github.com/qgis/QGIS/pull/6236

There is still a bug in the validator (which is basically not used) but I'll file a separate ticket (or - faster - just fix it)

#3 Updated by Anonymous about 6 years ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Closed

#4 Updated by Alessandro Pasotti about 6 years ago

  • Resolution set to fixed/implemented

Please test the latest commits, all tests should be done with a new project because the default widgets for fields have changed.

#5 Updated by Calvin Hamilton about 6 years ago

The issue is resolved.

Also available in: Atom PDF