Bug report #11504
Rotate Features Maptool does not take position initial mouse click into account
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | - | ||
| Affected QGIS version: | 2.4.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19774 |
Description
When you try to rotate one or more features using the 'Rotate Feature(s)' tool, it seems that after a mouseclick (so start rotating) the 'preview' (rubberband) often prerotates already, making the rotation maptool a little akward to use.
I found that EXCEPT when you click/start exactly on the east of the anchor point (the little red + in the center) you see this behaviour.
To test:
- create a layer with one polygon (make it a clear arrow shaped triangle, pointing to north)
- now select that layer and in it that polygon
- make layer editable and select the 'Rotate feature(s)' tool in the 'Advanced digitizing' Toolbar.
- Now click at the exact north position of your triangle and move just one pixel (meaning: just one degree)
- as soon as you moved your mouse, the red rubberband preview will point 90 degrees further
After some testing and debugging, I came to the conclusion that the rotating algorithm takes into account the rotating from the directed line from 'anchorpoint' to 'current mouse position', BUT does not take into account WHERE you started.
History
#1
Updated by Richard Duivenvoorde about 10 years ago
I've fixed this, and currently preparing a pull request ...
#2
Updated by Nathan Woodrow about 10 years ago
Is this in master now?
#3
Updated by Richard Duivenvoorde about 10 years ago
#4
Updated by Nathan Woodrow about 10 years ago
- Resolution set to fixed/implemented
- Status changed from Open to Closed