Show relation/member IDs somehow

[easbar]

There is this list of members for a relation (and similar the list of relations for an element)

This allows us navigating to the corresponding elements by a simple click. However, it is hard to distinguish the different members (like the two u-turn relations here). My current workflow would be clicking on a member and then copying the 'View on openstreetmap.org' link to extract the ID, but that is rather cumbersome, especially because after clicking a member there is no way to go back to where I came from. Update: Ok this is possible by clicking the relation we came from in the list of the relations of the member we clicked at least. The 'backward' button opens a pane saying 'Select Feature Type' for some reason.

[tyrasd]

I usually rely on the highlighted map features to distinguish the relations/members in such cases: when you hover over the corresponding relation (or member), the map view will show the respective elements in a blue highlight (in addition to the yellow highlight for the currently selected feature).

At the moment, iD does (by design) not visually expose the OSM element ids anywhere. I'm not sure what real benefit showing the id would bring, except maybe to be able to distinguish situations like where two members have the same title vs. when an element is member of a relation twice. May I ask you to elaborate a bit further how displaying the id would help in your use case?

The 'backward' button opens a pane saying 'Select Feature Type' for some reason.

Oh… currently, the "backward" button is not actually a "backward" button, but rather a secondary way to get to into the preset selection mode. The hover text of the button was just wrong there – that's fixed now in 78d37fd.

I guess having a proper history of selected elements with real forward/backward buttons could indeed be useful for these situations. 🤔

[1ec5]

At the moment, iD does (by design) not visually expose the OSM element ids anywhere.

iD does display the selected element’s ID in the History and Measurement panels, but these panels are rather out of the way and don’t apply to a feature that you’re just hovering over. Also, relation IDs do appear when selecting a relation from a list if a relation is unlabeled or if two relations have the same label. However, this text isn’t selectable.

Maybe it’s finally time to add a context menu to (that part of) the inspector? 😬

I guess having a proper history of selected elements with real forward/backward buttons could indeed be useful for these situations. 🤔

#6783

[easbar]

I usually rely on the highlighted map features to distinguish the relations/members in such cases: when you hover over the corresponding relation (or member), the map view will show the respective elements in a blue highlight (in addition to the yellow highlight for the currently selected feature).

Yes, this is very helpful indeed. And maybe it would be even more helpful it it wasn't flashing slowly, but constantly highlighted in blue as long as the relation/member link is hovered. Another minor thing: The 'remove' icon hint could be a bit more detailed, like 'remove member/way/node from relation' (for relations) and/or 'remove current feature (way/node) from relation'.

At the moment, iD does (by design) not visually expose the OSM element ids anywhere. I'm not sure what real benefit showing the id would bring.

In some places it is exposed and even required. I used the OSM id for the following:

• search for an OSM element (after pasting the id into the search field we get links to the corresponding node/way/relation that also show the id)

• add a node/way to an existing relation: In the 'add to relation' dialog I pasted the relation id into the 'Choose a parent relation' text box.

except maybe to be able to distinguish situations like where two members have the same title vs. when an element is member of a relation twice.

Yes, I think that was my problem as well. I was trying to figure out which one is which when there were for example multiple restriction relations for a given way and they were using the same title (=restriction value).

May I ask you to elaborate a bit further how displaying the id would help in your use case?

I was trying to remove a restriction relation and found out that in order to remove a relation I need to remove all members from the relation (which is not entirely intuitive when you do it for it the first time btw). So I opened the relation (by pasting the id in the search field, see above) and started clicking on each member and then clicked the remove button of the relation for that member. So I had to make sure I removed the right relation if there were multiple ones (and sometimes there were multiple ones with the same name, see above). Even being able to hover the relation title and see a little hint popup that has the id would help. Also I was urged to click the 'back' button to go back to the relation I came from to select the next member, but unfortunately that does not work as we discussed already.
However, at that time I did not realize that I can stay in the relation detail dialog and remove the members directly by clicking the 'remove' icon for each member...

That said, I still think displaying the OSM id would make editing more transparent. Right now there is a big 'Edit Feature' title:

and I would feel more confident if it was something like 'Edit Way 8652584', because that is what I am doing. The feature type and id are exposed anyway by the 'view history' link. But maybe that's just me, so please ignore this if it does not really fit with other design decisions.

[SomeoneElseOSM]

I usually rely on the highlighted map features to distinguish the relations/members in such cases: when you hover over the corresponding relation (or member), the map view will show the respective elements in a blue highlight (in addition to the yellow highlight for the currently selected feature).

Alas, that doesn't work in most cases. A superrelation will by definition include the same ways as a child relation; it is impossible to tell using just this mechanism which one to add to. Also, a hiking route relation and a bicycle route relation will often share the same name and some of the same ways - you have to combine the geographical information from "mouse hover" with iD's interpretation of relation tags (in those cases where it understands them.

Somewhat related to #9942 .

[1ec5]

When you go to add a feature to a relation, the dropdown list does disambiguate identically labeled relations by their IDs. Here’s what it looks like if I create two type=route route=bus ref=100 relations (but it also works with preexisting relations):

However, the disambiguation doesn’t show up when listing the existing memberships. This would be a nice improvement.

By design, the IDs also don’t show up if the two relations already have different labels:

A type=superroute relation’s label already differs from an otherwise identically tagged type=route relation’s label, so iD doesn’t append the IDs in that case:

Incidentally, #8276 tries to make the labels differ in more cases by appending directions and destinations to the label. Unfortunately, this gets unwieldy quickly, especially when the sidebar is narrow. It also fails when the two relations have basically the same tags. Ideally, the relation list would hide the extra details unless two or more relations would get the same label, then progressively show the extra details, just like it does with relation IDs. I wanted to do this for #8276 but was unable to figure out an elegant way to work that into the existing call hierarchy. It might become more important with an implementation of #9026.

[SomeoneElseOSM]

When you go to add a feature to a relation, the dropdown list does disambiguate identically labeled relations by their IDs.

Is there any way to get from the numbers shown there to an OSM browse page that let's you see the difference between the two relations? I've just hit this again with https://www.openstreetmap.org/relation/1761919 , https://www.openstreetmap.org/relation/11328997 and https://www.openstreetmap.org/relation/10521621 . Is it possible to click on the name somehow to open an OSM browse page (usually called "View on openstreetmap.org") before selecting a relation?

[1ec5]

The links to the browse page in the inspector and in the History panel are only available once you select the relation. (This is also true of other element types, not specific to relations.)

Are you describing a situation in which you’re inspecting a feature that’s already a member of these relations, or one in which you’re choosing a relation to add the feature to? If the former, it would be pretty nice if the blue label were an actual link to the browse page; iD would intercept clicks to select the relation as usual instead of opening anything. This would allow you to Ctrl/Command-click to open the relation browse page in a new tab. Other Web applications do this with permalinks to good effect.

[SomeoneElseOSM]

Both, actually. Here's the location: https://www.openstreetmap.org/#map=18/53.73240/-1.07252 . I was trying to see what was already added to what relation, and also decide which relation to add new ones to.

[1ec5]

For the new relation dropdown, it would also be nice to linkify each item. This would have the side effect of triggering your browser’s built-in URL status bar panel on hover. However, I vaguely recall that the control we’re using for these dropdowns doesn’t readily support embedded links at all.

[SomeoneElseOSM]

(continuing conversation from #10103 )

it would be great if the membership editor would show the relation IDs when two relations have otherwise identical labels

Actually, it would be great if it could do that at all times. iD doesn't know the context in which I am searching - it might be "is this relation number correct". Names may be similar, but not identical. Unless I can see the relation number, I can't be sure.

The potential "labels already easily get cut off when the sidebar is at a reasonable width" issue could be solved by (optionally) showing the relation ID - the most important piece of information by far - at the start, not at the end.

I would even go so far as to suggest formatting the numbers with digit grouping

Please no. JOSM does this, and it makes relation IDs significantly harder to understand based on a "glance" because the thing that I'm comparing them with (the OSM website) doesn't use digit grouping for them.

[1ec5]

The potential "labels already easily get cut off when the sidebar is at a reasonable width" issue could be solved by (optionally) showing the relation ID - the most important piece of information by far - at the start, not at the end.

I think most users would disagree with you about the relation ID being the most important piece of information by far. It certainly is for your use case, but not for the majority of edits that take place in this part of the UI.