Relation member navigation

[slhh]

Exploring an existing relation is currently a nightmare using iD, especially if members can't be identified by the name shown in the members section.
The current workflow is:

1. scroll down to members section,
2. jump to member,
3. view data,
4. scroll down to membership section,
5. find the relation again,
6. jump to relation,
7. scroll down to members section,
8. count members to fine the next one
9. repeat from 2. for each member.

In order to simplyfy this, the vertex navigation can be generalized as a parent child navigation covering relation/member similar to way/vertex.
The shortcuts can be reused and a graphical equivalent like it is proposed in #3603 can be added to the membership editor.
This would reduce the workflow shown above to a single keystroke per member. Users need to be able to explore the existing data easily in order to understand OSM datastructures.

If acceptable, I might work on this issue myself later.

[bhousel]

I had considered this a little. I think what you want to do is jump previous/next way along a relation, like a route relation.. But I'm not sure how it would really work in practice.

It's easy to do previous/next vertex, because you usually see a bunch of vertices on the screen at once, so jumping between them is not confusing.

But with relations, child member ways could be really long.. The user wouldn't see very well where they jumped to. Also a way can have many kinds of parent relations that don't follow similar semantics.. e.g. - you highlight a segment, and say "next"... Next what? It could be the next segment in a route, or the vertex in a turn restriction, or the next segment in a multipolygon. Or anything.

I kind of have my doubts about how useful this would be.. Also I'd like to figure out how to style route membership first.

[slhh]

I think what you want to do is jump previous/next way along a relation, like a route relation.

This is one one appllication. Some other examples are:

• Visit members of a site to remove the name which has been added to the site.
• Explore a level of relation which are members of a toplevel relation. (site of sites, moultipolygons of multipogons, segmented routes, etc.)
• Check and tag the bus stations of a bus route

But with relations, child member ways could be really long.. The user wouldn't see very well where they jumped to.

The viewport should not be changed as long as the way starts in the viewport in order to let the user watch the start position. We can just let the user scroll manually to the other end, or maybe we can reuse the "\" shortcut in order to center the viewport on the invisible end of the way.
Relations consisting of long members aren't the real focus for improvement anyway, mapping bus routes etc. in urban areas, where the highway is split every 50m due to turn lanes etc. is much more inefficient, and really needs improvement.

Also a way can have many kinds of parent relations that don't follow similar semantics.. e.g. - you highlight a segment, and say "next"... Next what? It could be the next segment in a route, or the vertex in a turn restriction, or the next segment in a multipolygon. Or anything.

You have the same problem in the vertex case: When selecting a connecting node there are multiple ways. Which one to stay on?

The solution in the generalized case is also the same. You need to select the parent (relation or way) and go down to the child (member or vertex), which makes the parent the parent to stay on.
Alternatively you can select the parent to stay on directly in the all relations or all connected ways section of the child.

[1ec5]

You have the same problem in the vertex case: When selecting a connecting node there are multiple ways. Which one to stay on?

Potlatch 2’s solution to this problem is to stay on the most recently selected way (or pick a way if none of the ways has ever been selected). It also has a / shortcut for cycling among the ways joined at the currently selected node.

Potlatch 2 doesn’t have a way to navigate linearly among the members of a relation, but it does have a way to select all the members (#2152) which – combined with editing a multiple selection (#1761) – makes the use cases described above quite convenient.

[slhh]

I have integrated keyboard member navigation into my pull request #3631.
The logic used to determine the related parent is similar to the case of a way, but has some differences.
To set a relation as the related parent:

1. Select the relation first and select one of its members afterwards.
2. Select the relation, and press one of the vertex jump keys, which become member jumps in this case.
3. Set the related parent explicitly using membership editor (future option).

This is similar to the case of way, but the logic to determine the related parent just from its selected childs only is dropped in the relation case, because it would be too confusing.

The logic to reset the related parent does also have a little difference for relations in case of a multiselection: The related Parent is kept as long as the first selected entity is member of the related parent independent of other selected entities. For example this allows a future radial menu operation adding shift selected entities in front of the selected member to the related parent, which would be very useful for relations requiring a well defined sequence of members.

[1ec5]

#8264 and #8577 implement keyboard navigation between ways and their member vertices. The same keyboard shortcuts used there would make sense for navigating between relations and their member ways. However, I think it’ll be a bit more complicated to extend it to relations, because a relation’s members aren’t guaranteed to be loaded yet: #6656.