Make radial menu operations aware of related parent

[slhh]

Where node or way density is high or evenen coincidence exist, it can be hard or impossible to make the right multselection for the way plus vertex based operations.

With the solution for #3634 the relatedParent logic becomes deterministic enough to be used for specifying the way part of such operations, and #3603 makes the related parent more visible and graphically changeable.

Maybe we can drop such operations from working on multiselection later, the radial menu is already quite full for the line+vertex case.

[bhousel]

Sorry, I don't understand what this issue is about. Could you describe what you think should be changed?

Where node or way density is high or evenen coincidence exist, it can be hard or impossible to make the right multselection for the way plus vertex based operations.

Why wouldn't a user just zoom in if the density is too high to edit? (I agree way coincidence is an issue we should fix eventually, tracked on #1239).

[slhh]

The related parent should be considered as the second operand, as if it were selected, for the operation as long as this makes sense in the specific situation.
First examples:

When clicking split here, way B (related Parent) should be splited, but not way A. Currently iD splits both ways.

Second example:

When clicking disconnect here, way A (related parent) should be disconnected, but B and C should remain connected. Currently iD disconnects all ways.

When clicking split here, way B should probably be splitted, because way A doesn't make sense as an operand here.

Why wouldn't a user just zoom in if the density is too high to edit?

When editing larger features this might become quite inconvienient, especially where ways are nearly coincident, which requires very high zoom levels.

[edpop]

I tried to do this in https://openstreetmap.us/iD/master/, it works correct.

[slhh]

@edpop I have made the sceenshots with the official release, but master deployment shows the same behavior.
The halo of the way in my sreenshots is not the breathing one of a selection, but the weaker one of the related Parent Way, which is used for keyboard vertex navigation. I think you might have misunderstood this.

[edpop]

Yes, now understood. I noticed, that after this split operation one of the ways gets 'related' class, when you select other way.

[bhousel]

Sorry to close this, but I don't want the related parent to be used for anything other than vertex navigation right now. It's not very well documented, and doesn't really render very prominently.

I think it's best for users to continue to specifically click to select one of the parent ways if they want to control how the vertex gets split or disconnected.

[slhh]

@bhousel
It doesn't render very prominently, but dependent on background color already prominently enough to be confusing.
The weak rendering might be a problem with the current related parent logic, but the improved vertex navigation logic #3634 would generate a more intuititve workflow and much less unexpected behavior.
I'm sure, it would be quite useable with weak or maybe even no rendering of the related parent.

In addition the improved vertex navigation logic #3634 would be much easier to understand and explain. This would relax documentation requirement, and it would make documenting easier.

The current logic is quite hard to understand. In fact I haven't understood it myself, before I have analysed your code.

Related parent awareness of the operations would affect the split and disconnect where these operations should be better disabled otherwise #3926. Therefore, the related parent based operations would have very little negative impact.

I think it's best for users to continue to specifically click to select one of the parent ways if they want to control how the vertex gets split or disconnected.

This would be ok in simple standard situations, but it can become nasty or even impossible in other usecases, e.g.:

• In some regions landuses are glued to the highways. Having to disconnect many nodes here is a quite nasty thing.
• Splitting or disconnecting the correct one where lines are coincident might be even impossible.

In addition the related parent based operation wouldn't need shift selection. This would be a benefit in case of an iD version for mobile devices, because such essential operations needs to be easily accessible.

[bhousel]

In addition the improved vertex navigation logic #3634 would be much easier to understand and explain. This would relax documentation requirement, and it would make documenting easier.

I don't understand it..

This would be ok in simple standard situations, but it can become nasty or even impossible in other usecases, e.g.:

In some regions landuses are glued to the highways. Having to disconnect many nodes here is a quite nasty thing.

I agree that people really shouldn't glue landuses to highways... Whenever I've wanted to disconnect them, I've just been able to use the [/] vertex navigation and keep hitting D, and this seems to work well enough.

Splitting or disconnecting the correct one where lines are coincident might be even impossible.

People really shouldn't create coindicent ways either (aside from indoor mapping).. I have definitely run into this a few times, and while it is annoying, I doubt splitting here is "impossible", I just split them all, delete the extra segments, and put them back together the way I want them.

In addition the related parent based operation wouldn't need shift selection. This would be a benefit in case of an iD version for mobile devices, because such essential operations needs to be easily accessible.

I understand it's frustrating to see issues closed that you want to see implemented, but I don't want to spend time now optimizing vertex keyboard navigation or changing how related parent works - this is already a expert-ish feature that doesn't benefit many users.