Opened 7 years ago
Closed 5 years ago
#3319 closed defect (fixed)
v.overlay: incorrect results with "not" operator
| Reported by: | sbl | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 7.4.5 |
| Component: | Vector | Version: | svn-releasebranch72 |
| Keywords: | v.overlay | Cc: | |
| CPU: | Unspecified | Platform: | Unspecified |
Description
In a project I want to clip away the sections from a river network that are within lakes.
Unfortunately, some streams vanished from the result completely (which should not)...
Data is here (sorry it is 5-11 MB): http://vm-srv-finstad.vm.ntnu.no/vpack/
The failing command I tried was: v.overlay --overwrite --verbose ainput=Streams_WR14695_merge binput=Lakes_WR14695_erings operator=not output=Streams_WR14695_test
Tested on three different boxes, with GRASS 7.2.1svn, 7.0.6svn and trunk.
Lines that disappear are e.g.: cat 8725 15481
Change History (12)
comment:1 by , 7 years ago
follow-up: 3 comment:2 by , 7 years ago
Thanks Markus for looking into this!
I just tested and after a visual inspection of the results the issue looks fixed.
Will you backport it or do you want me to test more systemically before backporting?
comment:3 by , 7 years ago
| Priority: | major → normal |
|---|
Replying to sbl:
Thanks Markus for looking into this!
I just tested and after a visual inspection of the results the issue looks fixed.
Will you backport it or do you want me to test more systemically before backporting?
I have backported the fix to relbr72 in r70703. In theory it is still possible that lines are missing or are kept erroneously, but this would require more substantial fixes to Vect_break_line() and Vect_break_line_list(). Reducing priority.
comment:4 by , 7 years ago
I would actually suggest to close this and open a new ticket if others errors come up.
comment:5 by , 7 years ago
| Milestone: | 7.2.1 → 7.4.0 |
|---|
In the particular case where I stumbled upon the issue, the fix seem to cover all cases.
However, if these errors still can occur, it is probably only a question of the number of features processed if the problem shows up?
Thus, I would probably prefer to keep it open and re-target. But of course I would not object if you close it...
comment:6 by , 6 years ago
| Priority: | normal → minor |
|---|
This only bites in rare corner cases, so degrading priority to minor.
comment:8 by , 6 years ago
| Milestone: | 7.4.1 → 7.4.2 |
|---|
comment:12 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I have not come across more cases where this pops up. So, closing it.
Replying to sbl:
Please try v.overlay in trunk r70800.
The problem lies with Vect_break_lines() and Vect_break_lines_list() which create new vertices that are sometimes too close to existing vertices (floating point representation error). Radim was aware of that problem in v.overlay. I (hopefully) fixed the symptom in v.overlay. The real fix would be to not use a fixed value for rethresh (Radim was also aware of that problem) in Vect_line_intersection() and Vect_line_intersection2(), but instead set rethresh to the smallest representable difference (ULP).