Ticket #5427 (closed enhancement: fixed)
Extrude leaves unnecessary nodes and 'antennae' segments when extruding again in a direction
| Reported by: | Ldp | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Component: | Core |
| Version: | latest | Keywords: | |
| Cc: |
Description
As outlined in http://lists.openstreetmap.org/pipermail/merkaartor/2010-September/002637.html.
1) Extruding in a direction that you already extruded in works fine, but the nodes of the earlier position remain. As the edge they're in is straight, these usually don't need to remain in the way.
2) When you extrude too far and want to pull back a bit, two nodes will remain at the original location, still connected to the way being extruded. These currently have to be manually cleaned up, but it would be nice if Extrude could take care of that.
Attachments
Change History
Changed 17 months ago by extropy
-
attachment
extrude-patch-1.diff
added
Do not add nodes when segments colinear, more directions to extrude to
comment:2 Changed 17 months ago by extropy
- Summary changed from Extrude leaves unnecessary nodes and 'antennae' segments when extruding again in a direction to [PATCH] Extrude leaves unnecessary nodes and 'antennae' segments when extruding again in a direction
Here is a fix, that improves the extrude function.
Can somebody review this and possibly commit?
comment:3 Changed 17 months ago by stoecker
When you do such long patches a bit larger description is helpful, as reading the code is not so easy.
comment:4 Changed 17 months ago by extropy
Sorry for the long patch. The original code was quite messy, so I could not resist reordering methods and renaming variables.
Changed:
- replace undo stack manipulation hack on mouseDragged with something a bit saner.
- improved mouseUp to not introduce new nodes, when segments are colinear (the main point of the patch).
- added mechanism to define several extrusion angles with automatic angle matching, depending on drag direction - see possibleMoveDirections list and it's uses.
- made three possible extrusion directions, one perpendicual to segment and two parallel to adjacent segments.
- moved geometry code out in separate methods (hopefully to be moved out into some tools class).
Also trivial improvement to WaySegment class to make code more readable.
comment:5 Changed 17 months ago by bastiK
Could you add Shift or Alt modifier such that it retains the normally superfluous nodes? I can imagine some use cases for this, e.g. drawing a cross shaped building:
- draw single segment
- extrude to rectangle
- extend 2 times
- you have a rectangle with 2 nodes on the long sides -> extrude these middle segments
(If we would introduce extrude today, it wouldn't matter, but there may be users who are accustomed to the old behaviour. Then we can tell them to hold Shift / Alt modifier. :) )
Otherwise the improvements are great, can you add the additional angles to the "move-segment" mode (Ctrl), as well?
Maybe one could also snap to angles of 45 deg. But I'm not sure it is a good idea.
Changed 17 months ago by extropy
-
attachment
extrude-patch-2.diff
added
Improved patch, cal extrude in additional directions when moving, always adds nodes if SHIFT is pressed
comment:8 Changed 12 months ago by Andygol
- Status changed from closed to reopened
- Version set to latest
- Resolution fixed deleted
comment:10 Changed 12 months ago by stoecker
- Summary changed from [PATCH] Extrude leaves unnecessary nodes and 'antennae' segments when extruding again in a direction to Extrude leaves unnecessary nodes and 'antennae' segments when extruding again in a direction
comment:11 Changed 12 months ago by anonymous
Looks like the problem is inside org.openstreetmap.josm.tools.Geometry, method segmentsParralel(). There is used constant 1e-13 to compare distance, but this is not working anymore because of change in Mercator projection.
comment:12 Changed 12 months ago by Ldp
While someone is fixing that, can he/she change it to the correct 'parallel' ?
comment:13 Changed 11 months ago by stoecker
- Status changed from reopened to closed
- Resolution set to fixed
In [3939/josm]:



I will take a look into this.