Disconnect point should select point wisely

[finetjul]

When "disconnecting" a point connected to areas A and B. The newly selected/current point is undefined for the user. It might be a point of A or a point of B. It seems to depend on the way those 2 areas have been connected (a point of A got connected to a point of B or a point of B got connected to a point of A). There is no way for the user to know which point (of A or B) will be selected/current once disconnected.

I would suggest instead to select the point of the area that has been the last one to be selected. For example, a point P is connected to areas A and B :

• select area B
• disconnect point P
• move point P
  -> it moves the point of area B

[bhousel]

Yeah this is something that I find annoying too. It almost always chooses the wrong way when I am disconnecting points. I also had the thought of separating the new points away from each other by a few pixels (because you really never want the disconnected points on top of each other). It wouldn't be hard to do, but I'm not sure what people think about that.

[finetjul]

@bhousel, I'm not sure I would like the points to move, I usually want to move only 1 point and leave the other one where it is.

[slhh]

@finetjul

I would suggest instead to select the point of the area that has been the last one to be selected.

I'd agree, but the example seems not to to be exact. I think it should be:
A node P is connected to areas A and B :

1. select area B
2. select node P
3. disconnect
4. move the selected node
   -> it moves the node of area B which is no-longer P, but the new node generated by disconnect.

We can do this based on #3634, which is already part of my pull request #3631, by #3635 .
Area B would become the related parent in step 2 due to #3634, and this would be used in step 3 due to #3635.
This would also make disconnecting multiple nodes quite easy by continuing with hitting pgDn (Next vertex) and "D" (Disconnect) alternatingly.
Main usecase would be landuses glued to highways, which are quite common in some regions, but very nasty to handle with current iD.

@bhousel

I also had the thought of separating the new points away from each other by a few pixels (because you really never want the disconnected points on top of each other).

In addition to giving the user control which feature is disconnected as suggested above, it makes sense to move the new node a few pixels, but not the original one.

[1ec5]

#6904 proposes an affordance for the specific case where a way is selected before disconnecting the point.