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

Hello, you added name to river Тотели (way/7981400). How you determine this name? I'm unable to google it.

bus#8, not bus #2

I tried to apply these changes again, but there are several conflicts now and I'm afraid, that new changeset will add some errors (due to wrong conflict resolution) and/or will be reverted again, so leave it as-is.

'simplify way' is useful tool and its usage for abovementioned lines broke nothing as I can see.

First 3 lines was edited manually as I remember. There were too much nodes, so I used Tools->'simplify way' with maximum error = 1 meter.

Last line (wood multipolygon) was edited due to JOSM warning. Something about multipolygon and building are cross each other. Seems, this is abnormal situation, so I edit mulipolygon.

Thanks, didn't know about it.

JSOM report validation error on way/304526745#map=17/41.914449/45.475963 :
"type=multipolygon on a way. Should be used in a relation (1)."
Likely mistype and need to remove this key-value, but I never worked with multipolygons so not sure. If you mean something else, fix error please.

1. I used NAPR data only for river names, is it prohibited? If yes, what source must be used as source of truth in such case?

2. BTW, seems, some data from NAPR available under GPL: https://geonetwork.napr.gov.ge/geonetwork/srv/v2/api-docs. Don't know what exactly available via this API.

3. Some data, available via maps.gov.ge, also available via OpenAerialMap: https://map.openaerialmap.org/#/45.482003688812256,41.918022134043206,15/user/6512afa748232300010f60ce?_k=lipiwi This is exactly same images - positions of moving cars are same.

Hello, I use 'associated street' relation almost everywhere instead of specifying street name on each building to avoid duplication.
Not sure, that I use this feature correctly. Whether this is ok?