Node dragging enhancement

[slhh]

1. Esc should cancel dragging.
2. A bounce back of a failed midpoint drag should also undo adding the vertex.
3. Disconnecting drag of vertex:
   When Shift is pressed, dragging a vertex of a selected way should disconnect it from the non-selected ways or a tagged node.
   This would address Possibility to detach a node from a way #4320, Disconnect point should select point wisely #2206, partially Handle coincident features (i.e. multiple things one spot) #1239, and likely the main usecase of Disconnect entire landuse areas from lines #4245.
   The risk of leaving coincident nodes would be eliminated.
   When a relation is broken, an on-map warning should be shown. The warning should automatically disappear, as soon as the relation is fixed. We need to prevent the operation until we have on-map warnings. The requirement to break relations would be reduced anyway, because the operation is very specific.
   The Shift drag gesture would be shared with the lasso selection, like panning and node dragging are sharing the normal drag gesture. Sharing doesn't seem to be an issue here because lasso selection is much less frequently used than panning, and the disconnecting drag would be limited to vertexes of selected ways only in contrast to the normal node dragging.
4. More specific midpoint drag:
   When Shift is pressed, dragging a midpoint of an edge should insert the new vertex into selected ways, but not into other coincident ones. This is partially addressing Handle coincident features (i.e. multiple things one spot) #1239.
5. Drag based activation of draw mode to reshape an area or line according to Allow to continue drawing of area #2272 (comment)

[slhh]

6. Placing the node well is impossible, when the node is out of view, or while the map is auto-panning. We should nope class the target when the cursor is outside of the inner auto-panning frame. Btw, this does also apply to the move operation.

7. Dragging a node, which is neither selected nor has a selected parent, should make the node the selected element (similar to JOSM). This would make the user more aware of an accidential drag, and also make make verification of dragging the correct node easier, if it is tagged.

8. We might also think about limiting the dragging distance.
   The main advantage would be reducing accidential dragging while panning, but there would also be a benifit for OSM history.
   In view of OSM history I don't see any usecase why a single vertex needs to move a far distance. What has to be considered as far seems to depend e.g. on node density.
   Some usecases of a far POI move seem to exist, e.g. a relocating shop or admin center.
   Some internal editing vertex dragging usecases seem also to exist, but these should better generate new nodes instead of node versions. Otherwise, relevant changes of the way history get hidden in the node history.

   If we limit the dragging distance in general, there are some potential exceptions:

   • Dragging of a new node (e.g. midpoint drag), which seems to address the internal editing usecases.
   • Dragging of a selected node.
   • Dragging of node of a selected way

   When exceeding the limit, the drag might be bounced back, or be accepted with a modal warning.

   We might make the move operation available for single points to cover the rare long distance move requirements. Workarounds would exist anyway, e.g. multiple dragging steps, or adding a dummy point to the selection to make the move operation available.
   Also using the Alt key to override the limit would be an option.

[bhousel]

I agree with 1. and 2. and everything else is just too much for me to even read.

[bhousel]

Ok, I've had a chance to read it all.. @slhh I know you are enthusiastic about improving iD, but I'd really appreciate it if you can keep the issues to be concise and actionable, and in line with the overall design principles of iD.

I know we've previously suggested that you might want to fork iD and change it into the kind of editor that you want to use - I still think that might be the best idea.

I'll respond to the rest of the points in more detail, now that I'm sitting at my computer.

points 3 and 4 -
iD's interface needs to be simple over everything else. I'd prefer to not re-use existing key modifiers or user interface concepts for things that they don't already do.

Shift-click-drag makes a lasso around things. This is written up in tutorials about iD, and we mention this on the keyboard shortcuts screen. It's the same gesture that people can use to select multiple files in every desktop user interface, and to select multiple points in every drawing application. It's a known thing. Repurposing Shift-click-drag for special tricks when dragging midpoints or untagged nodes is 1. not intuitive, 2. puts more of a burden on me to explain to people, 3. puts more of a burden on users to learn. Let's not do this.

point 5 - is already covered in another issue.

point 6 - I agree that placing a node while panning shouldn't be possible, and I'll check to see if the code actually allows this or not. I don't want to necessarily "nope cursor" the node, because that means "you can't put your node here", not "you need to stop panning for some milliseconds before you're allowed to drop it" (again, good UI design uses a single concept to mean a single thing).

point 7 - I'm pretty sure that the reason that we don't immediately select the node when it's being dragged, is because then all the other nodes along that way stop being rendered. It would make adjusting the way shape (the main usecase for dragging) more complicated than it needs to be.

point 8 -
Again, this gets into the consistency of the user interface. I don't want to have different dragging rules for different kinds of vertices / nodes (tagged vs POI). How would we explain to people that they can only drag some nodes far and other nodes not? It's clearly useful to drag all kinds of nodes far in some situations. Also, we don't care about the impact on OSM history. OSM needs to be able to deal with people dragging things all the time. The map is always changing and becoming more accurate.

[Slawek234]

In this case, examples of cases that the above suggested changes may improve should be given.
In my opinion node dragging enhancement is already overdone.
What is the result of further limiting the possibility of editing?

The id editor is still a light alternative for JOSM when adding handwritten many small new points, or quickly editing wikidata tags etc. in a large, huge area. But how long?

""We might also think about limiting the dragging distance."" It could be useful in the JOSM editor:)

[Slawek234]

If the ID editor is to be more resistant to mistakes made by new mappers, maybe he should have a lite version to the edition that would offer full potential after some time?
e.g. up to 20000 Map changes lite version.

[JamesKingdom]

@Slawek234 This was brought up in #3692, but as iD is designed with newbies in mind, so adding a "Newbie mode" really doesn't make sense.

[slhh]

@bhousel

point 7 - I'm pretty sure that the reason that we don't immediately select the node when it's being dragged, is because then all the other nodes along that way stop being rendered. It would make adjusting the way shape (the main usecase for dragging) more complicated than it needs to be.

Of course we shouldn't unselect the way, when dragging one of its vertices. That's why I wrote: "nor has a selected parent".

In contrast keeping the selection when dragging a totally unrelated node seems to be quite strange, and I don't see a relevant usecase for this. The selection should be changed in case of dragging these unrelated nodes only.

point 6 - I agree that placing a node while panning shouldn't be possible, and I'll check to see if the code actually allows this or not. I don't want to necessarily "nope cursor" the node, because that means "you can't put your node here", not "you need to stop panning for some milliseconds before you're allowed to drop it"

I had the same doubts, but I realized the nope class is fine here:
The user can't put the node there, and has to move the cursor inwards to stop auto-panning.

The released code allows to place the node e.g. behind mode buttons, and even behind the inspector or the URL, and anywhere in the auto-panning margin.