Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deleting Features from Shapefiles on Network Drives #20789

Closed
qgib opened this issue Apr 30, 2015 · 4 comments
Closed

Deleting Features from Shapefiles on Network Drives #20789

qgib opened this issue Apr 30, 2015 · 4 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented Apr 30, 2015

Author Name: Miles Shugar (Miles Shugar)
Original Redmine Issue: 12682
Affected QGIS version: 2.8.1
Redmine category:vectors


We are a small GIS department of 4 folks working with a shape file composed of points. We have local installs (C:) of QGIS 2.8.1 on our workstations, which run Windows 7 x64. The shape file in question is installed on a network drive.

Lately we have noticed that, only sometimes, deleting a single point causes the attributes of the remaining points to be replaced with those of the next record in the feature set. For example, say we have 3 points, all with a field called "Label." The labels of the 3 points are as follows: FOO.1, FOO.2, FOO.3. I want to delete FOO.1, so I do so using the tool in QGIS whose icon is a red trash can, either in the map canvas or in the attribute table of the layer. The point "FOO.1" is deleted from the map and the attribute table, but now the point "FOO.2" has the attributes of the point "FOO.1," and moves to the location of the deleted point. This glitch seems to cascade down the attribute table, affecting all subsequent points in the layer and moving attributes from one record to another.

In searching for similar glitches to this one, our team has discovered the documented bug #828 from 6 years prior that seems to replicate our situation.

Unfortunately, the documentation doesn't seem to suggest a solution for those folks like us who store their layers on a drive separate from the one where QGIS is installed.

I was wondering if anyone else has come across this documented bug during their workflow, and if so, they have found sustainable ways to work around it. We have come up with a temporary solution to fix the problem of "rolled back" attributes, that is, loading the table as a .csv file and manually fixing the unique IDS associated with the features to accommodate the deleted record. However, this is not a long-term solution.

If the only solution turns out to be that we need to temporarily move our layers to our local drives and only edit them there, that'd be just fine, but we want to make sure there isn't some other simpler or more elegant solution.


Related issue(s): #10887 (duplicates)
Redmine related issue(s): 828


@qgib
Copy link
Contributor Author

qgib commented May 1, 2015

Author Name: Regis Haubourg (@haubourg)


Hi,
could you share a shape example before / after editing?
Are you editing shp concurrently ? In this case, there is no other solution than moving to a relationnal database server that handles concurrent editing in transactions (postgis, oracle, mssqlserver). Even Sqlite is not multi-user enabled..

@qgib
Copy link
Contributor Author

qgib commented May 4, 2015

Author Name: Giovanni Manghi (@gioman)


  • status_id was changed from Open to Feedback
  • category_id was configured as Vectors

@qgib
Copy link
Contributor Author

qgib commented May 8, 2015

Author Name: Sandro Santilli (@strk)


  • fixed_version_id removed Version 2.8.1

@qgib
Copy link
Contributor Author

qgib commented May 22, 2015

Author Name: Giovanni Manghi (@gioman)


closing for lack of feedback. Please reopen if necessary.


  • resolution was changed from to not reproducable
  • status_id was changed from Feedback to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats) labels May 25, 2019
@qgib qgib closed this as completed May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

1 participant