split way: Option to decide which part will keep original id (WAS: Undesired route continuation)

[ghia]

JOSM has a feature that when a new route is started at a point with other roads already connected, it will continue a single road ending in that point.
In favour of this behaviour is the ease of copying the probably similar tags to the continuing road.
However there are a lot of serious side effects.

• The relations which are copied, can form a tail.

Also when a backward route is continued and afterwards splitted, the original history of a road switches sides and become history of a total unrelated part of the road.
​http://www.openstreetmap.org/browse/way/82861117/history
​http://www.openstreetmap.org/browse/way/98440181
This is completely defeating the Wiki character of OSM, because the history is disguised in other parts.
Also not attributing the historic part of a road is the way JOSM operates for splits of a road.
When you have a road with 10 points from A to J and jou split at I then you have a road with 9 points that has the history and one small new two points road.
When you split at B, you get a small road with the existing number and a large 9 points road which is new and this does unjustice of the original contributor and the Wiki.
Assumed previously is that the road points forward from A to J. With pointing backwards, from J to A, the effects are the same, but now for the other cases.
JOSM should check for the part with the most points and keep that as original and give the new id to the smallest part.
For the road continuation, JOSM should only connect the new way to an old after confirmation by the user. It should also provide a list with elements (tags, relations ) so the user is aware about the consequences.
Other useful thing would be a similar tool like a colour pipet in graphic editors.
It allows to copy all tags of a road segment to another.

[stoecker]

• Simply press <ALT> or <ALT-GR> when drawing the first segment to stop continuation.

• There is already a "Paste Tags" function in josm (edit menu).

[skyper]

I am not sure if the history is safed.
The problem is in split way.

I often have to revert a way before splitting to get the original id on the correct part. If the way has tags with left/right or oneway=yes and is child of route relations with role=forward/backward, it

Would be nice to have an option to decide which part of the way will keep the original id, or a function to change after split like terracer has it.

[stoecker]

As long as OSM has no feature to refer previous objects this is a wontfix. Whereas it may be possible to select better data for the followup object this very soon gets much to complicated to be handled properly. Also if your really want a complete object history, the changesets can be used to build one.

[ghia]

Unwanted behaviour

""Simply press <ALT> or <ALT-GR> when drawing the first segment to stop continuation. ""

I think you did not fully understand the problem. I try to explain it better.

The problem is when you have a node A with some existing ways B-A-C and D-A, and you start in node A a new way to some new point E, it continues on D-A and makes it a way D-A-E automaticaly. This should be prevented or only allowed by user action.
Since it does this also on backwards ways (from A to D) it has then its start in E and makes a way E-A-D.
When the user sees then that the edit resulted in a big old way E-A-D and not in the single new way A-E, he will split it at A. Since the old id is always kept with the first segment seen in the forward direction, the id and history is now moved to road E-A and the existing road from the begin of the edit is entered in OSM as a new road.
That's what is demonstrated by my example links for the Verstrekenstraat from the first post.
Another example of such a mangle that results from it is here at the Jachtdreef:
​http://www.openstreetmap.org/browse/way/51768961/history
​http://www.openstreetmap.org/browse/way/108859153/history
​http://www.openstreetmap.org/browse/way/97836493/history
The resulting mess is still waiting corrections.

An example of a node to test this unwanted behaviour is:
​http://www.openstreetmap.org/browse/node/803205990
Suppose you want to add a track into the wood as a dead end.
You select the node and then clicks the way drawing tool.
Do a click in the wood (direction SE) and then escape to end the segment and then you end up with an extended path of Voetweg 48.
Oh no, I wanted to add a track! Why is it not a blank road?
Oh, never mind, we split the result at the starting node and change properties of the new added part, which has now inherited the id and history of Voetweg 48. And on top of that the original Voetweg 48 will be presented from now on in the database as a new way created by you, while you even had no intention to modify it in the first place!!
JOSM should only make continuations of ways on request by the user, to avoid these unintended messes.

Splitted roads:
In the interest of the Wiki, I think JOSM should transfert the id (and by consequence the history) to the largest part (most nodes) of the splitted road and not defaulting it to the first part (see my previous 10 node example). The smallest part would then get the new 0 id.

As a stopgap, I try to do a reverse of the road before and after splitting, when I need to split a road and noticed the starting part would become the smallest. So, I don't see the need of any reference to OSM previous objects. When a road is splitted, give the id to the largest part in stead of the first part and it is done. (I know that subsequent splits afterwards (or in the future) may make that the id will end in a smaller part, but that's not the point)

[stoecker]

What you call unwanted behaviour is an essential part in drawing when you loose focus (which happens very often, e.g. when doing undo). Such an feature will not be dropped for the sole purpose of getting a clean history in one single case of hundreds of possibilities.

OSM has only rudimentary change history presentation and when you look a bit deeper into the topic you will recognize, that a proper solution very likely does not exist at all. We have the changesets which allow to link changes together. When you really want proper history, then find someone who does changeset analysis and constructs a changes tree from this. And this task would be easier than what JOSM must do, as JOSM would need to trace that stuff over lot of editing steps, whereas the changeset is the final result of all these minor steps.

BTW: I can construct dozens of examples of valid editing, where your "choose a better way" would be exactly the wrong thing to do.

[ghia]

And you are right, OSM history isn't that clear, but these 2 'quirks' prove to be a deadly combination in disguising it entirely.

For the splitted way, I don't see the programming difficulty for that. Nor that it should have a big impact. It is just for making an additional test, to move only the smallest group of nodes to the new road part. As I assume that splitting a road is only creating a new way, duplicating the tags and moving the nodes in the second part (by copying the splitting node and move the following nodes upto the end) to it. It seems as easy to me for moving the first part (from begin to before the splitting node and then copying the splitting node) to the new way, if this part turned out to be the smallest of the two.

I don't ask for more.

But if you do see it to difficult or don't see any benefit, then it is like that.

However, the automatic continuation of roads is the real unwanted behaviour of JOSM and that prolongation should be done only on users request and consent! (See my node 803205990 example. Did you try it?)

In the node 803205990 of the Onderbosstraat, there is a T-joint, but JOSM should NOT assume that when I want to add a road starting on this crossing, that it should be a continuation of Voetweg 48.

Eg only continuation when the way and node is previously selected at the way drawing start. Maybe as exception, automatic continuation of ways should only be done when started in the node at the end of a road with a dead end (node at the end of a way, not part of any other road), but even then, I fear that the prolonging will not always be what the user intended or expected.

This 'feature' should definitly be corrected.

[skyper]

Replying to ghia:

Eg only continuation when the way and node is previously selected at the way drawing start. Maybe as exception, automatic continuation of ways should only be done when started in the node at the end of a road with a dead end (node at the end of a way, not part of any other road), but even then, I fear that the prolonging will not always be what the user intended or expected.

At least with an untagged way [id:0] it is definitly wanted to be continued.

[ghia]

Replying to skyper:

Replying to ghia:

Eg only continuation when the way and node is previously selected at the way drawing start. Maybe as exception, automatic continuation of ways should only be done when started in the node at the end of a road with a dead end (node at the end of a way, not part of any other road), but even then, I fear that the prolonging will not always be what the user intended or expected.

At least with an untagged way [id:0] it is definitly wanted to be continued.

I don't know. It is not the way I add ways. When I have to add a way, I add it completly by subsequent clicks placing all the nodes. Then I set all tags for this way and then start another way, which is obviously AN OTHER way. Eg. a track starts in the middle of an existing way and at its end, it continues as path. When the track is added and the tags are set, I start a new way at the end of the track for the path. That JOSM will incorporate this new way as part of the track is very unconvenient, annoying and unproductive, as it has to be splitted, and changed to path with possible deletion of any unwanted inherited tags from the track.

In fact I see only very limited use of this automatic continuation. The default should be to add new ways. For the case a continuation is needed, the user can use the tool for combining ways or select way and end node togheter before starting to draw nodes.