use addr: tags as a fallback name

[k-yle]

Closes #8744, Closes #7327, Closes #3857, Closes #2001, Closes #1760, Closes #1524

When adding or editing addresses, the changeset upload page is not very helpful since all addresses are just called "Address". This makes it hard to review what changes you have made.

This PR makes use of the addr: tags to provide a fallback name for a node/way/relation, if there is no name or ref tag.

before	after

[mbrzakovic]

I very much like the idea of using addr:tag values as displayName fallbacks.
There are 2 things I noted while looking into code:

1. I don't think we should use translations as a solution to address formatting. Correct me if I am wrong but my understanding was that translations depend on users locale, while the address display format(order) should be dependent on entity location (as done in uiFieldAddress). These two are orthogonal concepts, meaning user can prefer China locale and still edit an entity in US.

• I think the idea, that @1ec5 suggested above, using address_formats.json + locale lookup based on entity location is a valid solution and does not take much additional work. I've setup up small branch-change that demonstrates this.

2. utilDisplayName has a wide usage, so we should be more carefull with this change.
   e.g. The current code would also enable map label-rendering for nodes that have icons and have 'addr' tags which I am not sure we want...
   
   Actually I see the opertunity for this PR to have a bigger impact by covering wider types of entities (not just address nodes) and wider use-cases (not just the original images in PR's initial comment)
   e.g. Building/Multiselect - Features dropdown (this looks better then having just 3 x Apartment Building)
   

I am interested in your opinion on this.
Bellow is the full table of displayName usage, please look it over/populate in which situations do you think addr:fallback should be used. @pnorman @k-yle @1ec5

<style> </style>

Item	Usage	Description	Alternative - Full context	Addr fallback?
svgLabels	displayName, displayNameForPath	Condition and rendered text for map labels display	None. No displayName => No rendered label
ui\uiSectionSelectionList	displayName	Sidebar - Multiple select - items display	'Featuretype' 'displayName'
ui\uiFeatureList	displayName	Sidebar - Search (none selected)	'Featuretype' 'displayName'
ui\fields\raw_member_editor	displayName	Inside a relation when editting Members	'Featuretype' 'displayName'
ui\fields\raw_membership_editor	displayName	Relations (from editting standard node\way)	Relation 'displayName'
ui\fields\restrictions	displayName	Click on Node (Traffic Signals), Turn Restriction, hint on hover	Yes. displayName. If none then featureType
ui\sections\uiSectionChanges	displayName	After clicking Save in sidebar - Listing name of changes	Created 'FeatureType': 'displayName'
keepRight,osmose,improveOSM	displayName	Click on issue, inner text can contain displayName	Yes. displayName. If none then featureType
uploader	displayName	Conflict detection - Displaying conflicts	Yes. displayName. If none then displayType + id
hash	displayLabel	Browser tab name when entity is selected	Yes. displayName. If none then featureType
paste	displayLabel	Paste annotation	Yes. displayName. If none then featureType
validations*	displayLabel	Displaying issues on Save menu	Yes. displayName. If none then featureType

[1ec5]

Actually I see the opertunity for this PR to have a bigger impact by covering wider types of entities (not just address nodes) and wider use-cases (not just the original images in PR's initial comment)

That’s a good point. This non-name-based labeling parallels what we’ve already done for route relations, which are labeled in various places based on secondary tags like from. By labeling more tags, we would make mappers less likely to put redundant information in name.

Bellow is the full table of displayName usage, please look it over/populate in which situations do you think addr:fallback should be used.

These situations all seem reasonable or at least harmless. (It seems unlikely that an address would show up in the turn restriction editor, for example, but it’s probably better to let that happen then complicate the code with a special case.) It is worth noting that some areas have a lot of buildings with addresses but no names, or a lot of address nodes without names. In these areas, the user will see many more labels than before, similar to the effect in openstreetmap-carto. I think that change would be reasonable, but it’ll likely be a significant visual change in some places.

The screenshot above shows some “undefined undefined” labels on buildings on the map. Is that because the address format loads too late, or something else?

[mbrzakovic]

@1ec5 Thanks for the comment.

The screenshot above shows some “undefined undefined” labels on buildings on the map. Is that because the address format loads too late, or something else?

Great vision :) Please disregard it, I did a quick local change to demo the 'multiple features'.

[mbrzakovic]

link - #1524