Why 'Охкури' was changed to 'Оххури'?
See also https://ru.wikipedia.org/wiki/Охкур

I've fixed 'name:en'.
Pass named after girl with name 'Nadya', Word 'Нади' is correct (peculiarities of russian grammar), but similar situations translated using "main" form of name usually.

Don't know, how name:ka must looks like and what variant must be placed in 'name' tag for border points.

Sorry, but where did you find such names (especially name:ge)?

I understand, that name "Молчечнорт" was initially added 9 years ago by somebody else, but you specified 'Genstab' as source of data and seems it named 'Малчечкорт' there. See also: https://ru.wikipedia.org/wiki/Малчечкорт
and GGC: https://nakarte.me/#m=15/42.73857/44.71397&l=O/K&nktl=ayZy8N-kLtyvSR_BWRNRWQ

I've reverted this changeset (see changeset/186563009).

Let's check thoroughly, before submitting such massive changes.

The problem not with naming, but with locations of the points. There are no passes *at all* at places, where you marked it. Check topo maps (i.e. with height levels) for example.

More examples:
1. Sofrudzhu Yuzhnyi (node/14042104637) with height 3283m placed almost inside village at the level ~1330m. The real pass: node/4462074525

2. Okrila (node/14042104663) with height 3100m placed near the river on the height ~1800m. NB: guess, there is mistake in caucatalog also. As I can see on photo there Оксана/"Oksana" pass was meant (which must me somewhere near Khazny glacier relation/8083105).

3. pass '46th army' (node/14042106294) have meaningful 'name' tag, but obviously wrong names on other languages (and even 'name:ru' tag). Location also wrong.

In fact, I'm unable to find at least one correct point. How did you do this changes? You specified source as 'survey'. According to OSM wiki "This means the author was physically nearby the object", but you edited 373 passes, I'm doubt, that you were near all of them.

BTW, changeset message is "Added label in other languages ...", so editing of existing points is expected, but (almost) all points are the new one.

Didn't check all changes, but possibly even safer to revert whole changeset.

At least some of passes here have absolutely wrong locations.
See for example:

1. Nenskra Zapadny (node/14042104639)

2. Shirokoe sedlo (node/14042106265)

3. Nakhsvi (node/14042106208)

One relation is better. I meet relation:street for the first time, so avoid editing.
BTW, as I understand, need to add sidewalks to this relation also.

Thanks, don't know, how can I miss this. Possibly because .tm is top-level-domain for Turkmenistan.

Hello, seems this changeset is wrong. See
changeset/181362737#c1584520

Deleted addr:street tags contained wrong info, so I have right to delete it.
Compare:
ვახტანგ ბოჭირიშვილის ქუჩა
ვახტანგ ბოჭორიშვილის ქუჩა

This is good example of why relation better, than addr:street on each building.

Hello, JOSM complains on relation/16895285:
he said, that role should be outer.

I don't understand, what did you want to draw here and why need to map simple rectangular building as multipolygon. Fix this JOSM error please.

Was wrong date in message.
Jan 2025 -> Jan 2026.

I returned street names for buildings, that have it before my changes as promised. Still decide to leave these buildings inside relations.
See changeset/177804687

Hello, as I understand this monument existed in 1970s (https://pastvu.com/p/1952152) and Stalin's statue was added and removed much later.

So seems it's wrong to tag this monument as designated to Stalin, mb need to fix wikidata also.

Agreed? If yes, can you fix this? I have fresh photos, if you need (https://mega.nz/folder/IsVgTRYT#1ni-DEYwR4bvziDYI7iYlg).

Removing is needed to avoid duplication and follow single responsibility principle.

About street vs associatedStreet: I don't know, what is better, mb you're right. Propose to discuss outside of this changeset.

Sorry for delay.
1. I think it's bad idea to wait for support from ALL renderers. This is quite old well known feature of OSM, so we can expect support from mature renderers.

2. I don't know, how and why osm.org fill names of objects on provided view but think, that this was done intentionally, because it "knows" about AssociatedStreet relations. See for example this view: relation/18749306#map=18/41.688534/44.837663.
To be clear, this part (i.e. pane with list of results) of osm.org is not 'renderer' (as I understand) - no need to work with graphics to produce names for URL links. May be Nominatim responsible for this.

3. About "And the renderers are not required to processed it ..." this link said nothing about requirements to renderers.

I think, that AssociatedStreet approach is strictly better, than addr:street for most cases, because
1. it allow to avoid data duplication.
2. easier adding tags for the whole street (name in different languages, etymology).
3. some minor pros: defense against typos; easier renaming; clear behaviour for difficult cases (2+ streets with same name for one city); easier validation and improvements (just look at associated street view and and see, whether all adjusted buildings added to relation, whether some was added by mistake, etc).

So I can't understand, why you need this addr:street tags. It it really because of search results view on osm.org?

I created a lot of AssociatedStreet relations for Telavi and nobody complains. If building contained addr:street I removed it usually.

I can add addr:street back for my Kojori-related changes (and I will remove these buildings from relations, so there will be one source of truth).
This will lead to situation, when half of buildings on street will be mapped via addr:street and another half - via AssociatedStreet. This is ugly, for me.

As alternative I propose next: I'll move whole Kojori to AssociatedStreet relation (with removing addr:street) and we will see, whether this will lead to problems. For the period of testing I will not remove addr:street for buildings outside of Kojori&Telavi.

Why associatedStreet is not replacement for addr:street? What the purpose of having addr:street on houses, that present in relation?

From osm.wiki/Addresses:
"The associatedStreet relation provides a link between houses and streets. This can be used as an alternative to the addr:street=* tag. "

From osm.wiki/Relation:associatedStreet:
" Its purpose is to centralise some tags on one single object to avoid data duplication or mismatching names"

Because it is wrong from one side (border of landuse cross building and fence) and more or less useless from another side (it just claims, that area with 2 buildings inside city is 'residential area', which is by-default assumption).

Sorry, fixed url: way/79814001