Id: object history handling while split way function

[sun-geo]

It seems the current process and handling of the object histories (of a line/way element) is like the first part depending on the osm-way direction gets a +1 higher version number and the second part gets a new way-id with version#1.

first-part:

second-part:

So the current only ability of manual intervention of history handling of the two new way-parts is to reverse the osm-way direction of the initial way object before splitting.

Today a had a short trip to JOSM-editor (only because, I'm still waiting a bit for #6539 - undelete object function ;-) ), and I was facing an interesting message while the Split-Way function: It asks me for:

So it seems it is not needed (to work through the workaround - with potential failure producing when missing to reverse back in case of a oneway road) to reverse the osm-way direction and you can decide while splitting which part will get a new way-id.
Is this something which could please also be implemented for iD?

[quincylvania]

@sun-geo Hmm this is a type of UI that sounds great for JOSM, but I don't think suits iD's usability goals. I'm assuming very few iD mappers know about entity IDs and version numbers, so asking them this question would be unhelpful. However, iD could be smarter when deciding which part to increment rather than simply picking the first part.

[sun-geo]

Thanks for checking and thinking about.

.... I'm assuming very few iD mappers know about entity IDs and version numbers, so asking them this question would be unhelpful.

I agree.

What about an idea of a bit hidden function to add instead a new context menu item (after right click) only active for the second way part (w-1) (which has no object id & version yet). Let's say a function which is called "Get history"- (get the version history information from the other split way segment). So, the average iD user would not bothered with confusing questions about history & versioning. The users, who know about the OSM history and version concept, would have the possibility to adapt the object histories and would have it quite easy to respect the achievements of other users who had previously worked on these objects.

However, iD could be smarter when deciding which part to increment rather than simply picking the first part.

I don't have an idea, how to change the procedure. It's fine so far, if it isn't wanted to ask the user something similar like JOSM is doing it.

By the way, maybe forgot to tell. There is another background of some general splitting requests. There are mapping cases when you want to (have to) disconnect a shared junction node, but sometimes the disconnect function is blocked/(greyed out) for these nodes, because the node is an end-node of a way-segment which is a member of many relations. So the workaround for the blocked disconnect function would be the splitting and deleting steps. And for splitting and saving the object history you have to (as explained above) work through the other workaround (namely the reverse function).

PS: There is another use case of splitting (& deleting & take care for the history) when working with areas which have a connected way object on their outline (and if the way is member of relations). The workaround to not create MP's is well explained here: https://github.com/openstreetmap/iD/issues/969#issuecomment-350927272

[quincylvania]

Okay, I made iD maintain the history on the longer of the result ways, which I think would be the desired behavior most of the time. It's a bit harder to manipulate if you want to force the history onto the shorter way, but this isn't really something most iD mappers should be worrying about.

[maro-21]

This is a good change, thanks!