| 3 | | To me this is a no-brainer, but I may be missing something. I feel like this command is used in ways not originally intended when it was created. I'll fix it if I get agreement. |
| | 3 | 1. Currently if you use the '''Replace Geometry''' command and one or more of the source or target way's nodes are tagged, then it's likely that the tags will either be lost (as the node is replaced by another), or the tagged node will be moved to a location where the tags may no longer be valid (barrier=gate, entrance=building, etc.). I think this command should only be allowed to operate on non-new (uploaded) ways which don't have any tagged nodes, or at least don't have nodes with interesting tags (non source,fixme, etc.). The replacement way could have tagged nodes, but if the nodes are replaced with id>0 nodes, the tags should be transferred. |
| | 4 | |
| | 5 | 2. I've also noticed that relations can become corrupted when using this command. First we need to decide if relation memberships should transfer; I think it makes sense to do this at least for outer/inner, maybe ask every time? If not, then we should not allow touching objects that are members of relations. I've gotten NPE's when replacing the geometry where the new way is part of a multipolygon. |
| | 6 | |
| | 7 | 3. If replacement nodes are greater than 3e-4 degrees (hardcoded) from the other nodes, the nodes aren't moved & transferred. I think by default there should be no limit to the distance, but have it settable in the preferences (using meters instead of degrees. |
