Support addr:place tag in Address field

[tyrasd]

This adds support for the addr:place tag in the Address field (closes #2898).

A demo instance is available.

This changes the "Street" subfield of the Address field to a combined "Street / Place" input element which is little bit more clever:

• If an address has no addr:street, but does have an addr:place, it is displayed
• The dropdown offers not only nearby street names, but also nearby names of places¹, which are made distinguishable by an icon
• When selecting an option from the dropdown, the correct tag is used addr:street for streets, addr:place for places (and in case a different tag was previously present, it is removed automatically)²
• When manually entering a string into the box, the correct tag will be used if the entered name matches a nearby street or place from the dropdown.
• When manually entering a string which does not match any nearby street or place names, the addr:street tag is used as a fallback

Not all countries have this "enabled", as in some countries the use of place names in addresses is non-existent in OSM (e.g. Latvia), or use a special "non-standard" addressing scheme which allows for both addr:street and addr:place to be set at the same time (e.g. Czech Republic).

The following countries I'm currently unsure about, and would really appreciate some feedback by the local community how they would like to be handled in iD:

• Taiwan has currently (iD v2.25.2) both addr:street and addr:place enabled (see Add Taiwan (R.O.C.) address format #3261), but I don't know whether this was just done as a hacky workaround to allow map either addr:street or adr:place (but never both), or if it is actually possible for an address in Taiwan to have both tags set at the same time. I assumed that the latter is the case, as before Add Taiwan (R.O.C.) address format #3261 was merged only 63 out of ~120k addresses had both tags in the country (for comparison: today the proportion is still pretty small, but the absolute number has increased significantly to 2.1k out of 1.5M). It would be nice if someone from the local community could confirm or deny this. //cc @david082321
• In the US and Canada addr:place seems to be very rarely used, but one pattern I noticed is for addresses on sites which are only accessible by boat (example 1, 2). In this PR I have currently not enabled the addr:place tag for these countries (my reasoning for this was that offering place names in the dropdown list of the "street field" could be confusing if it is such a rare thing to see in an actual address). However, this could be enabled easily. It would be nice to hear from the community what approach would be preferred in the US and Canada.
• The following countries also currently only the the "old" addr:street-only field, because they seem to not use addr:place in practice (and for these countries I had to make a decision because they already had localized address formats defined in iD): Australia, Finland, Iceland, Liechtenstein, the Netherlands, Norway, Monaco, Latvia, Peru, Bolivia, China, Ukraine, India (highlighted are the countries which I am a bit unsure about, similar to the US and Canada above, and would especially appreciate some feedback about). If further countries should be included in this list, it would be good to know what the local address format should look like (i.e. in which order the different parts of an address should be arranged into a typical list of "address rows").
• The Czech Republic and Slovakia seem to be quite complicated in their own ways. For now, I disabled the feature in these two countries (i.e. left it untouched to the status quo) because at least in Czechia it is possible that both tags must be used at the same time. To not digress from this PR's main point: Let's discuss how the quite complicated local address schema in these countries can be better represented in iD in a separate issue.

Footnotes

1. Map features with a place=* tag or boundary=administrative objects with admin_level>8 ↩

2. Note that this implies that if an address had (for whatever reason — most probably a mapping mistake) both addr:street and addr:place, selecting any option from the dropdown would remove the other tag from the type which one has selected (e.g. when selecting a street name, the addr:place would be removed). ↩

[1ec5]

In the US and Canada addr:place seems to be very rarely used, but one pattern I noticed is for addresses on sites which are only accessible by boat (example 1, 2). In this PR I have currently not enabled the addr:place tag for these countries (my reasoning for this was that offering place names in the dropdown list of the "street field" could be confusing if it is such a rare thing to see in an actual address). However, this could be enabled easily. It would be nice to hear from the community what approach would be preferred in the US and Canada.

@blackboxlogic asked about using addr:place before using it in that import, specifically for addresses on islands that lack streets. In my opinion, it’s quite an edge case, and I don’t personally think it’s necessary to facilitate additional usage of that tag in the U.S. Just as addr:city doesn’t necessarily name a city (and doesn’t even necessarily name a place), I don’t think it’s strictly necessary for addr:street to be a street, as long as it’s whatever would go in the “street” slot of the standard address format. After all, many addresses on college campuses have the name of a walkway where a street name would normally be. There wasn’t very much discussion about it at the time, so I’d pose the question again in Slack or the forum before enabling addr:place for the U.S.

The U.S. has some alternative address formats that would probably require a more significant rearchitecture of this field. For example, some rural addresses use rural delivery route numbers, which have no established tagging, while others use P.O. boxes (addr:postbox).

Puerto Rico has a unique series of standard address formats. There’s some scattered usage of addr:place there, but addr:street is overwhelmingly common.