Opened 12 years ago
Closed 12 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)
by , 12 years ago
| Attachment: | building bug segments.osm added |
|---|
comment:1 by , 12 years ago
Addition: Edited with JOSM/1.5 (5990 sv) in Windows 7, if it makes a difference.
comment:2 by , 12 years ago
| Component: | Core → Plugin building_tools |
|---|---|
| Owner: | changed from to |
comment:3 by , 12 years ago
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...
by , 12 years ago
| Attachment: | minimum.osm added |
|---|
comment:4 by , 12 years ago
Though if BuildingTools did not create such messy geometry, where would be no such bug...
comment:5 by , 12 years ago
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 by , 12 years ago
You were faster :)
Yes, Geometry.addIntersections is the source of the problem. Shift-I (Utilsplugin2) is creating the same buggy nodes .
comment:7 by , 12 years ago
| Component: | Plugin building_tools → Core |
|---|---|
| Owner: | changed from to |
by , 12 years ago
| Attachment: | absolute_minimum.osm added |
|---|
by , 12 years ago
| Attachment: | better_intersections.patch added |
|---|
comment:8 by , 12 years ago
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...
by , 12 years ago
| Attachment: | hard_case.osm added |
|---|
one strange case that gives extra hole after joining. Is it OK?
comment:9 by , 12 years ago
This looks ok, I did not see any regression :) The last strange case is already weird with current version.
comment:12 by , 12 years ago
For now, yes... Let us leave "hard cases" for new tickets after tested :)
comment:13 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
osm file, look for starvägen to find it