| 1 | | Reg. selection that contains only nodes: We could allow that if there is exactly one way which has all selected nodes as children. |
| | 1 | ~~Reg. selection that contains only nodes: We could allow that if there is exactly one way which has all selected nodes as children. ~~ |
| | 2 | No, I don't like that as well since the result is very different to the old current behaviour. |
| | 3 | This action is really a brain teaser ;) |
| | 4 | My understanding is this: the algo which caculates the move commands needs a center point **and** a radius and one or mode nodes which should be moved. My findings so far: |
| | 5 | - We must reject all selections which don't allow to find the center **and** radius. |
| | 6 | - the center can be specified by the user, either by selecting a single node that is not on the modified way(s) or by selecting one or more ways which form a closed ring and exactly two nodes of the way/these ways. This method gives the diameter and - if not yet known - the center for the circle. |
| | 7 | - If the center is not known a 2nd algo `Geometry.getCenter()` tries to calculate it. This algo needs at least 4 nodes and the nodes must match certain criteria, e.g. a (virtually closed) way that is drawn along the nodes in the given order must not be self intersecting, else this 2nd algo may calculate a wrong center. So, the order of the move-nodes is important. Different methods to select the nodes may produce different orders, and the user has no way to check this order without a debugging tool :( The only way to select the nodes in a specific order seems to be to select them one after the other in the wanter order. |
| | 8 | - if no center is given and the 2nd algo failed we must stop with a message like "Cannot determine center of circle for this geometry." |
| | 9 | - if a center is known the radius is calculated as average distance to each node from the center |
| | 10 | - selected move-nodes are fixed, means "angle relative to center should not be modified" |
| | 11 | |
