Id: Possibility to detach a node from a way

[yaugenka]

It's not a killing feature but let me post it anyway in case somebody finds it helpful as well.

The only usecase I have for this is correcting someone's mistake of a named node attached to a way..
E.g. on this screenshot you see a place node attached to a way and there are no means of correcting this in iD other than making a copy of this node and clearing the tags in the old one, but in this case you looe the history.

It would be nice to make it possible to deattached a named node from a line in such a way that a new node is created in the place of the original one and the latter is preserved.

[bhousel]

Agree, I actually wanted this feature earlier today too.

[bhousel]

See #2511 for a convoluted workaround. I closed that issue because I don't think shaking the node is a good way to detach it, but I'm open to the idea of some other operation to do it.

[jjiglesiasg]

Agree as well, very often I found this cases and correction take much time...

[jjiglesiasg]

Any news about this issue?

[bhousel]

Any news about this issue?

No news - you are free to work on it 👍

[jjiglesiasg]

Any way to add a Disconnect feature for nodes? in #2511 you show the "current" ways to do the fix, but it take a lot of time and worse if the "way" is a part of a "relation"...

[bhousel]

I'd do it like this:

• make actionDetatch which does the necessary changes to the graph (and add tests for it too)
• make operationDetatch which wraps actionDetatch into a nice menu command (and pick a key shortcut that will make everyone happy)
• add an icon for the menu too

[jjiglesiasg]

Love ID and all the tricks...

[slhh]

The usecase is relevant, but I don't like the suggested operation because it is generating coincident nodes. These are hardly visible, and iD is quite bad in handling coincidence. And also the whole change of the operation would be hardly visible.
Using the operation accidentially can break OSM data, for example when detaching a barrier from the highway.

What we can do instead:

1. Don't let the detach operation replace the vertex. This have its own usecases, especially if it can be used selectively in view of the way or even the position in the way to detach from.
   Unfortuneately, this doesn't support the special case of the original usecase well, where a tagged node is a connecting vertex.
2. We can implement the operation as originally proposed, but let it switch to move mode with the tagged node selected afterwards. This does unlikely result in coincident nodes, and the user gets aware of the operation because the node hangs on the mousepointer. Maybe, we can call that operation an "detaching move" or "move POI".

[bhousel]

We can implement the operation as originally proposed, but let it switch to move mode with the tagged node selected afterwards.

I agree, putting the user into move mode with the detached node already selected would be ok.

[1ec5]

Here’s the hack I do whenever a POI is incorrectly attached to a street or building, preserving history:

1. Draw a new line that also connects to this point.
2. Shift-select the building and the point, then right-click the point and detach the building from the point. Now there are two identical points at the same location.
3. Delete the line in step 1, leaving the original point as a standalone POI.
4. Move the standalone POI to the center of the building.
5. Delete all the tags from the point that’s part of the building (or delete that point from the building).

[Psigio]

Hi!

I created a pull request around this issue, but a comment on that pointed out that there is some complexity around dealing with relations on the node to be detached. I understand that in JOSM a pop-up is used to request more information from the user before carrying out the operation.

Is there already a model in use to request more information from the user and we could use that here (I don't recall seeing any pop-ups on the other actions, but perhaps I've just not seen them!)?

[bhousel]

This was done in #5127 - Thanks @Psigio 🙌