I checked the edits:
- POIs inside a parking (node/10184351554)
- restaurant (without amenity=restaurant) in the middle of a pedestrian way (node/10184351562)
ecc.ecc.

Teoricamente dovrebbe essere così,

ho visto che anche tu hai applicato lo stesso tagging ad alcuni roof, nel tuo caso qual era la logica?

way/918135452
way/918135453
way/1062934001

Questo check di iD è up dal 26 agosto 2018 e nessuno se ne è mai lamentato, ho dato per scontato ci fosse un consenso, anche perché esiste già un check separato sugli edifici sovrapposti a way, quindi direi che è deliberata l'aggiunta ai building che non si sovrappongono a null'altro. Se non sei d'accordo secondo me sarebbe utile aprire una issue su GitHub o commentare la issue originale https://github.com/openstreetmap/iD/issues/5204

+1 to ovruni

The import guidelines should be followed.
"Changing the bitcoin_bank tag again" is not what you are doing, you are adding POIs, in another CS with the same comment you deleted POIs, you are not "changing" the bitcoin tag.
The survey date is "fake" since this data comes from a dataset (as linked in a precious changeset from another user) and not from a survey.
The data from the dataset has no quality check (there's even a POI in the middle of the ocean as I pointed out in another changeset).
There are no descriptive tags of the places (are they shops? ATMs? Banks?)
bitcoin_bank:galoy:bitcoin_beach=yes isn't documented. Seems to follow a prefix logic but there's no other bitcoin_bank:*=* value in the database.

Imho all this data should be reverted and imported in the proper way following the guidelines.

Hi jslawin,

I'm not sure about this building: https://pewu.github.io/osm-history/#/way/1110071530

it's not visible in aerial imagery (but maybe it's a new one?) and is overlapped with the footway

Hi snoozingnewt,

how can this be a survey? It's 565 nodes with "survey:date=2022-11-14" added in south america, south africa, netherland, turkey and... the ocean ( node/10184351460 )?

Hi vindard,

is this import documented?
osm.wiki/Import/Guidelines

The name Kveseti was added since V3, and during time it become a mess, with Kiketi in some names (like name:fr), and Kveseti in others (like name:en). I don't remember what exact reasoning I had 7 months ago while doing this edit, but I had some doubts for sure since I see now I created a note as well: note/3134067

If you have local knowledge we can fix it, but then we would have two areas with the same name. If you confirm both areas belong to Kiketi village we can create a multipolygon having the two areas as outers.

ps. Are you Georgian? Do you know other Georgian mappers? There's a new OSM forum, it would be cool to have a Georgian community as other countries have.

Invece per quanto riguarda la minuscola del nome locale (occitano?) l'hai cambiata tu con questo edit: way/767933542/history

Ah boh, chiedilo a chi li ha aggiunti:
changeset/99890425
Nemmeno i nomi delle strade li ho aggiunti io

Io ho solo spostato un URL da description=* a website=* (come da commento del changeset)

Grazie a te, buon mapping!

Ciao meinmap,

sei sicuro di questa posizione? Un utente l'aveva già mappata piu' ad est un anno fa: node/8859692766

o ce ne sono due?

Hi,

what's the meaning of the building_part=neighborhood tag?

Grazie mille, buon mapping!

Ciao Matteo,

so che è un changeset di sei anni fa, ma Osmose continua a lamentarsi di questo elemento: way/439325076/history

dice che manca il tag information=*
presumo sia information=office?
information=*

Tra l'altro il civico lo avevi già spostato nella posizione corretta con un altro account in questo changeset: changeset/128208035

Il dato è corretto ora, dove lo vedi visualizzato ancora nella vecchia posizione? Probabilmente devi cancellare le cache del browser.

Visto che è corretto direi che il fixme si può togliere.

Hi msnritou,

please notices that names are not descriptions, name:en=swamp seems wrong to me.

Nope, mapping buildings as node is only less detailed, but clear to everyone and documented on the wiki. Mapping a building as building:part=no to tell the renderer that the element IS a building part is just weird, the value is not documented anywhere and the logic behind it goes against the current 3d mapping schema, which requires that "the entire building outline should be filled with building:part=* areas" (from the Wiki).

In your example you flag the outline as a building part to "save" an incomplete rendering, but why not using building:part=yes then?

building:part=no is semantically wrong and makes no sense. And is confusing to other people. You read that and think the mapper wanted to flag the exact opposite.

Scusami Balaabirami,

ma in quali foto satellitari e stradali hai visto marciapiedi ai due lati di ogni "braccio" della Galleria Vittorio Emauele" e cordoli a raso sulla pavimentazione a mosaico?

Hi KKK-jp,

node/9778674047

can the building:levels tag be moved to the building outline?

Ok I got what you mean (I think), from the Wiki:
"The building outline provides backward compatibility for 2D rendering software, such as Mapnik, and other data consumers not interested in 3D modeling. When a building has any building:part=* areas, the building outline is not considered for 3D rendering."

Imho this is "lying for the renderer". I don't think 3d renderers know what building:part=no mean, they don't care about the value at all (they don't render differently if it's building:part=balcony or building:part=column) so you are "lying" to the renderer telling him the outline IS a building part.

The proper solution imho would be to have a building:part with the same outline geometry. The difference is that in the building (not :part) outline is tagged with the attributes that are common to the whole building (such as the address) while the building part would be just there for the renderer (so without address). Also considere that the outline needs to have the max height, while the building part would have the outline height minus the roof height.

Maybe someone with better english can re-phrase this better.

tl;dr building:part=no is wrong imho and should be fixed with an additional building:part