Bug report #8395
split features is not working properly
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Digitising | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 17168 |
Description
Hi averyone,
in the current master on win, split feature is not working (no split is performed, and the message "an error occured during feature splitting" appears), if the cut line is not snapped at its start and end point to exixting features, not important if that to be splitted or other.
I checked this bug as blocker because it's a regression. older versions worked properly.
Associated revisions
History
#1 Updated by Alessandro Ciali over 11 years ago
just to be more clear, I'm referring to the split feature tool in the advanced editing toolbar.
Making some other tests, I found that the tool works correcly if the user create at least 2 further vertex out of the feature(s)to be splitted before ending the splitting line.
#2 Updated by Nathan Woodrow over 11 years ago
Could you attach a sample set because I can't reproduce it with my data.
#3 Updated by Giovanni Manghi over 11 years ago
- Status changed from Open to Feedback
- Operating System deleted (
windows) - OS version deleted (
win7)
I can confirm the issue also on Linux.
If just a straight line (with just two nodes) is drawn then qgis returns
"An error occured during feature splitting"
If the cut line has 3 nodes (2 before crossing the feature, or 1 before and 1 inside) then the cut operation fails silently.
If the cut line has 3 or more nodes, at least 2 after crossing the feature, then it seems to work, but edits are:
- sometimes discarded when saving
- sometimes are saved, but a previous saved cut disappear
- sometimes after finishing a cut
before savinga previous vanished cut shows again
messy.
#4 Updated by Giovanni Manghi over 11 years ago
- Status changed from Feedback to Open
#5 Updated by Denis Rouzaud over 11 years ago
This is due to the change of behavior of the right-click in digitization. Right-click doesn't add a new node.
#6 Updated by Denis Rouzaud over 11 years ago
A solution to a disambiguation would be to have distinct color/width in the rubber band for already drawn line and the line to the mouse cursor (possible next point).
That would require to add a second rubber band...
#7 Updated by Nathan Woodrow over 11 years ago
I don't mind that solution if it's easy to do. Sounds like something that would be nice for the normal line tools too.
#8 Updated by Matthias Kuhn over 11 years ago
Sounds good to me. Are you thinking about using two rubberbands with two distinct colors for that, one being always a temporary line with two nodes?
Another solution would be to add the possiblity to mark a point in the rubberband as "dangling/uncommitted" and change the rubberband paint method accordingly.
#9 Updated by Nathan Woodrow over 11 years ago
Denis are you planning on working on this?
#10 Updated by Denis Rouzaud over 11 years ago
I would have some time to do this, but we would have to discuss it first.
I would prefer Matthias' solution with a single rubber band. Having the last segment as a dash line would probably be a good way to go, but right now rubber bands do not handle this. Or we could play with thickness only.
Ideas?
I'll have a look.
#12 Updated by Nathan Woodrow over 11 years ago
- Status changed from Open to Closed
Fixed in changeset d3142f6d88db49f46e2e3fd87dd3a583ed6776b3.