Opened 10 years ago
Closed 10 years ago
#8851 closed defect (fixed)
Bug when combining building segments.
| Reported by: | Grillo | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | combine, building | Cc: |
Description
I have encountered this bug several times. It happens when I combine several building segments into one. Suddenly one or more of the ways flies away in one of the directions of the building. I'm using the building tools plugin, and usually draw the seperate parts of the building with one of the marked so it follows the same angle. From what I have collected, it might have to do with some node going a bit out of the completed polygon, if that makes sense.
Before combining
Before combining, zoomed in
After combining, zoomed out
After combining, zoomed in
This doesn't happen every time though. First time in this instance it bugged and I undid the edit. Then I thought I'd report it and it worked fine. Third time it bugged again. I use the buildingtools plugin, but I think this bug has more to do with the combine feature.
Attachments (5)
Change History (18)
Changed 10 years ago by
| Attachment: | building bug segments.osm added |
|---|
comment:1 Changed 10 years ago by
Addition: Edited with JOSM/1.5 (5990 sv) in Windows 7, if it makes a difference.
comment:2 Changed 10 years ago by
| Component: | Core → Plugin building_tools |
|---|---|
| Owner: | changed from team to Upliner |
comment:3 Changed 10 years ago by
This is not BuildingTools bug, as seems from description. Author forgot to mention he press Shift-J after drawing buildings.
This bug is reproducible, but zoom-dependent. It has to do something with intersection of parallel segments, I'm having a look...
Changed 10 years ago by
| Attachment: | minimum.osm added |
|---|
comment:4 Changed 10 years ago by
Though if BuildingTools did not create such messy geometry, where would be no such bug...
comment:5 Changed 10 years ago by
Also it seems the result is selection-order-dependent.
- Select left rectangle, then add top one, then bottom one, the result is OK.
- Select top rectangle, then add bottom one, then left one, the result is as on the picture (one line sticking out to the left, one downwards).
- Select bottom rectangle, then top one, then left one, the result is different again (one line sticking out downwards).
Similar result (new nodes at weird places) can be obtained by Shift-I (utilsplugins2's Add nodes at intersections).
comment:6 Changed 10 years ago by
You were faster :)
Yes, Geometry.addIntersections is the source of the problem. Shift-I (Utilsplugin2) is creating the same buggy nodes .
comment:7 Changed 10 years ago by
| Component: | Plugin building_tools → Core |
|---|---|
| Owner: | changed from Upliner to team |
Changed 10 years ago by
| Attachment: | absolute_minimum.osm added |
|---|
Changed 10 years ago by
| Attachment: | better_intersections.patch added |
|---|
comment:8 Changed 10 years ago by
Here is the patch that seems to fix the particular problem.
@team: It involves significant change in widely-used geometric function. It seems to work, eliminate bug and even give some speed-up, but could someone please check it before committing in stabilization phase?
I tested Shift-J on
http://josm.openstreetmap.de/browser/josm/trunk/data_nodist/Join_Areas_Tests.osm
and find it behavior weird enough, with or without the patch...
Changed 10 years ago by
| Attachment: | hard_case.osm added |
|---|
one strange case that gives extra hole after joining. Is it OK?
comment:9 Changed 10 years ago by
This looks ok, I did not see any regression :) The last strange case is already weird with current version.
comment:12 Changed 10 years ago by
For now, yes... Let us leave "hard cases" for new tickets after tested :)
comment:13 Changed 10 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
osm file, look for starvägen to find it