Dropdown should visually distinguish relations that already contains selected feature

[1ec5]

In the Relations section of the inspector, the “Choose a parent relation” dropdown menu should visually distinguish any relation that the currently selected feature is already a member of.

Problem

The dropdown menu in the Relations section of the inspector lists any nearby relations, including the relations that the current feature is already a member of. For example, this dropdown lists westbound I-275 and the Kings Island Job Connection even though the currently selected feature is already a member of both route relations:

This is by design, because the Public Transport v2 schema requires certain routes to contain the same members multiple times, and so do some turn restriction relations such as restriction=no_u_turn. However, most of the time, the user doesn’t really want to make a route loop back on itself or make a boundary double back on itself. Depending on the names or labels of these relations, the user might find it difficult to distinguish the already added relations from the ones that haven’t been added yet. In theory, the user can hover over each menu item to see its members highlighted, but this highlight clashes with the highlight for selected features.

Proposal

Instead of hiding and disallowing a redundant membership, as proposed in #7648 and #9311, the dropdown should visually distinguish the existing memberships somehow. For example, each affected menu item could be boldfaced or italicized, or ✔️ or ◆ could be prepended to the menu item.

Here’s the code that determines the contents of each menu item:

https://github.com/openstreetmap/iD/blob/37939c869ad4634c3c951085d27abc9f6be90d19/modules/ui/sections/raw_membership_editor.js#L284-L288 https://github.com/openstreetmap/iD/blob/37939c869ad4634c3c951085d27abc9f6be90d19/modules/ui/sections/raw_membership_editor.js#L297-L301

A different method in the same file gets the current memberships:

https://github.com/openstreetmap/iD/blob/37939c869ad4634c3c951085d27abc9f6be90d19/modules/ui/sections/raw_membership_editor.js#L70

[danieldegroot2]

See also replies starting from https://github.com/openstreetmap/iD/issues/10297#issuecomment-2226974018

Note, formatting/icon/fill may be confusing, i.e. green checkmark may be confused with 'best suggestion'. Also, I personally think a blue highlight is familiar enough to the user to not be confused with object highlights or similar.

If tyrasd's collapsed view suggestion is used, existing relations could have their own 'add' or 'duplicate' button instead of having to highlight/find these entries.

Sidenote: To find existing relation members in a large relation, unrelated members might need to be hidden temporarily for the user (like GitHub code search); though not sure if this is applicable/feasible for this issue.

[1ec5]

Also, I personally think a blue highlight is familiar enough to the user to not be confused with object highlights or similar.

Possibly, but for accessibility reasons, we shouldn’t rely solely on color to communicate this difference. It would have to be paired with some other formatting. Strike-through, even?

The doubled-up role boxes in https://github.com/openstreetmap/iD/issues/10297#issuecomment-2324775246 are intriguing, but it raises more questions than it answers, with extra 🗑️ icons and such. I’m hoping this issue would at least allow someone to chip away at the problem, even if the solution is imperfect, without actively preventing a user from entering valid data.

[danieldegroot2]

it raises more questions than it answers, with extra 🗑️ icons and such.

I assume these would only be shown if there are multiple members ('delete all', 'delete one'), like on comboboxes. See also https://github.com/openstreetmap/iD/issues/4565#issuecomment-347050201 (scroll up for an image)

The 'delete all' icon in this case could indicate it is such by adding the text 'all' next to it, or the number of items. (though this is inconsistent with current buttons)

[danieldegroot2]

I would suggest using a small black checkmark similar to the one GitHub uses (example for reference only)

[Ravish990]

@1ec5 Dear sir, I am Ravish . I am studying at Polaris School Of Technology , Bangalore ,India . I am interested on contributing to open source . I would love to solve the issue . Will you please assign me ?

[Ravish990]

These could be the solutions:-

1.Filter Already-Member Relations:

Modify the dropdown menu to filter out relations that the selected feature is already a member of. This ensures the list only shows potential new relations.

2.Highlight Existing Relations:

Instead of removing them, you can highlight the existing relations in a different color or style to indicate that the feature is already a member. This keeps the list complete while enhancing clarity.

3.Separate Lists:

Create two separate lists or sections within the dropdown: one for relations the feature is already a member of, and another for new potential relations.

[tyrasd]

The doubled-up role boxes in https://github.com/openstreetmap/iD/issues/10297#issuecomment-2324775246 are intriguing

If we use an approach like that one, it would make sense to also add a + button to the individual relation sections, which would be used to add an element to a relation for a second/third/… time. This would allow to remove the already present relations from the add new relation combobox (#9311), and makes the adding of a feature to a relation more then once very explicit.

[tyrasd]

@Ravish990 thanks for your willingness to contribute. However, as this issue is still under discussion regarding the concrete implementation, it's too early to assign at this point. Also, it's probably not a good issue for a first contribution, as it's about a relatively complex topic of OSM data modelling.

[Ravish990]

@tyrasd Thank you for considering my contribution. I understand that this issue is still under discussion and that it's a complex topic, perhaps not ideal for a first contribution. I appreciate you feedback . Sir can You tell me some good first issue . I would like to contribute.