Do not hide relations' pseudo-names

[DujaOSM]

When there are multiple available unnamed relations such as multipolygons, iD helpfully generates a pseudo-name such as "r-12" for uncommitted ones or "r82370591" for pre-existing ones. So far, so good.

However, the pseudo-name is hidden as long as iD does not see an ambiguity. For example, it is omitted for the already linked Scrub in the screenshot above. However, such hiding is not helpful, since the mapper does not easily know which relation is (or needs to be) referenced. Examples:

• On the screenshot, I want to assign the line to a correct Scrub. However, has it been already linked to R-5 or R-6 (so I select the other one)? It's hard to tell unless you go through hoops to activate highlighting.
• I start building a new scrub (say, r-8). I add several lines to a relation titled "Scrub" (no "r-8") on the UI. However, I scroll a bit further, erroneously moving r-8 out of view and moving another, r12345 into the view. I happily continue adding to a "Scrub", without any indication it's a wrong one. Everything's messed up as a result.

In sum, I think pseudo-names should be always displayed for all unnamed relations, both in drop-down lists and as already assigned relations. They do not do harm (that I can see) and are helpful for resolving ambiguities to the mapper.

[sun-geo]

I noticed similar behavior when working with route, admin or turn-restriction relations.

DujaOSM:

"However, such hiding is not helpful, since the mapper does not easily know which relation is"

That's true, you have to move the mouse courser to this member for displaying the relation-id in the bottom status bar/line.

For unnamed relations I would propose to don't use/add any pseudo codes. My idea is just to add the relation-id (which is displayed in status line, only after moving mouse coursor over the member) numbers in brackets behind.

@DujaOSM would that help?

(
Currently sometimes my workaround is to give admin relations temporary (pseudo) names, the bad thing for this workflow is: sometimes I forgot to remove the fake names before uploading :-(
)

[DujaOSM]

For unnamed relations I would propose to don't use/add any pseudo codes. My idea is just to add the relation-id (which is displayed in status line, only after moving mouse coursor over the member) numbers in brackets behind.

@DujaOSM would that help?

Well yes, but that's more or less what the iD already does (append a relation's real or pseudo ID), the issue is only where to display it To keep things simple, I'd prefer that the "pseudo-name" is treated in the same way as the proper name throughout (even drawn on the editing map itself, if possible).

Currently sometimes my workaround is to give admin relations temporary (pseudo) names, the bad thing for this workflow is: sometimes I forgot to remove the fake names before uploading :-(

When I know they're going to be complex, I name them "hotel", "shop" or "bakery" so iD will issue a warning when I try to commit. 😏 It used to work with "1", "2", etc. but not after v2.15.1.

[quincylvania]

@DujaOSM I've thought about this and I really don't think we should always show the IDs. I'm imagining a new mapper discovering relations for the first time and getting turned off by lots of weird numbers. We might think of more intuitive ways to differentiate relations, like #5407.

We recently did #3487 which lets you choose a specific relation from the dropdown list by specifying its ID. This workflow should be sufficient for linking to offscreen relations without ambiguity.

[DujaOSM]

I respectfully disagree, but it's your call. #3487 solves a quite different issue (I have to know the relation ID first, and in my use cases it even does not have to be committed), and #5407 is about identifying individual members rather then the relation itself. My primary concern is usability, where the editor can easily make an error because iD "prettifies" UI too much. Perfect is the enemy of the good here.

But I'm looking forward to #6551, count me in for beta testing if that's a thing.

[quincylvania]

My primary concern is usability, where the editor can easily make an error because iD "prettifies" UI too much. Perfect is the enemy of the good here.

@DujaOSM I appreciate your thoughtfulness and concern here. The issue here is that there is no "perfect" UI for all mappers. While always showing the relation IDs might make this UI more usable for some mappers, it would make it less usable for most mappers who don't know nor care what the IDs are. iD will always err on the side of the casual mapper.

That said, we definitely want to do things like #6551, #6465, and #2946 to make working with relations easier!