Can't see which relation to add to
URL
https://www.openstreetmap.org/node/3200102991
How to reproduce the issue?
Notice a broken multipolygon at e.g. here. Try and fix it by creating a new way to one side to allow mutlpolygons to be redrawn without the "figure of 8" that makes them invalid.
Screenshot(s) or anything else?
When trying to add relation to the new way I see this:
Because iD hides the relation number, I have no idea which relation to add.
Which deployed environments do you see the issue in?
Released version at openstreetmap.org/edit
What version numbers does this issue effect?
2.28.1
Which browsers are you seeing this problem on?
Firefox
I thought that I'd raised this before but can't immediately see an obvious issue - apologies if I've missed anything.
As you hover over each item in the list, you should see a tooltip that contains the relation ID, and the boundary should light up on the map if it’s within view.
By the way, the boundaries in this area are particularly gnarly due to all the historical mapping that has taken place. The local mappers might want to consider OpenHistoricalMap as a more optimal place for this sort of mapping.
(re the historical mapping) I'm trying to suggest that direction: https://community.openstreetmap.org/t/broken-multipolygons-in-clonskeagh/111221 .
Re the tooltip - it appears in some cases but not always:
It doesn't appear often enough to be useful, and it's not really "discoverable" even when it does.
The tooltip currently only includes the relation ID if the menu lists two or more relations with the same label (composed of the type, name, etc.). Personally I think it would be reasonable to have the tooltip include the relation ID always and the label include the relation ID only for disambiguation.
/ref https://github.com/openstreetmap/iD/issues/10103#issuecomment-1945426863
Even though this should hopefully[^1] not be required very often in practice, I would agree that in the rare edge cases where there are multiple relations with the same name, type (and other properties that might be included in the labels for relations), the dropdown should at the very least resort to fall back to include the OSM element id as the final way to distinguish these entries.
[^1]: It seems like the original issue has been resolved in OSM data by renaming the "duplicate" boundary to something more specific: https://www.openstreetmap.org/relation/6542469
(for the avoidance of doubt) I don't believe that the "making up a name" that you mentioned ("It seems like the original issue has been resolved in OSM data by renaming the 'duplicate' boundary to something more specific") is OK; as I said, and you agreed, elsewhere: https://github.com/openstreetmap/iD/issues/10343#issuecomment-2325069439 .
The solution is, of course to just show the relation number and shying away from this solution will cause these issues to keep occurring again and again :)
#10942 will add the relation id as a last-resort disambiguation for equally named relations in the membership editor:
Thanks - that'll be a definite improvement There are of course also cases where relation names have been made up with lots of words in that are very similar (also not helped by iD not distinguishing between "relations of relations" (whatever you choose to call them) and "relations of ways").
Edit: And please don't make it some undiscoverable "only display on hover" thing. just show the relation number.
Edit: And please don't make it some undiscoverable "only display on hover" thing. just show the relation number.
Just to set expectations: even if we append the ID to the unhovered label, it won’t be selectable, as clicking it will change the selection to the relation.
If we add the capability to include IDs unconditionally in the unhovered label, I’d suggest putting it behind a preference that’s off by default. Otherwise, it would add noise and potentially confuse users. For example, a newly added relation could have an (internal) ID of −4, resulting in a label ending in r-4, even though this could well be a legitimate ref for some kinds of relations or relation members.
even if we append the ID to the unhovered label, it won’t be selectable
I'm a bit confused by this - surely everything in the "select a relation to add this way to" list is selectable?
I meant in terms of text selection, for example, selecting the ID to copy it to the clipboard. Of course the relation itself is selectable for the purpose of adding to a relation.