> First, the owner considers it as a single building with multiple entrances (as you can see here, for example: https://gchg.ch/immeuble/liothard-41-45/ )

I don't think "Liothard" is edited by the owner. Presumably it would be able to spell the street name. If this was the source for the edit, I find this suboptimal. Did you query all buildings on that website and try to make it fit with OSM?

Well, as you more or less reverted the edit, the merged feature wasn't a single building .. the three we had were indeed removed. Maybe imagoiq has a good explanation for their change, but I find this type of editing problematic.

C'est bien que les points (1), (3) et (4) semblent désormais clairs et je peux compléter/fusionner les "features".

> Lorsque l'on récupère toutes les adresses suisses de la région du district de Nyon (ou tout autre admin_level comprendant cette partie). On obtenait avec votre modification une adresse française puisque l'hôtel (le chemin) est à l'intérieur de la Suisse.

Ce type de problème survient dans toutes les requêtes sur les districts ou départements avec des "features" chevauchent les frontières. La seule particularité ici semble être qu'il s'agit également de la frontière nationale et vous avez récupéré une adresse et des tags qui vous semblent étrangers.

Si vous cherchez à éliminer des données dans tous ces cas, on a un problème systématique. Avez-vous fait d'autres modifications similaires ? Si oui: dans quelles régions ?

>> (6) En quoi cela concernerait‑il la communauté suisse ?
> Il s'agit d'une adresse suisse.

Vous vous contredisez, car vous semblez vouloir éliminer de vos résultats une addresse française que quelqu'un a mis sur un lieu y situé. Donc la discussion ne concerne pas le forum de discussion suisse-allemand. D'ailleurs, votre problème de requête ne semble pas lié à ma contribution: il vaudrait mieux y publier un bref message d'excuses.

What was the basis for this edit?

Why did you delete the buildings?

There is a note complaining about it: note/5258755

Il y a un souci avec la reprise de la signalisation actuelle sur way/5190762 ?

A noter que Wikipedia n'est pas une source fiable pour les renommages et un changement du nom officiel ne garantit pas une modification sur le terrain.

Good to hear — a simple explanation is always helpful. I think remote edits should generally be reviewed locally.

Please allow me to be skeptical about daily edits by PT mappers: we don't all agree about the quality of the sources they use or the assumptions about the sources' information content. Local editors tend to know when a bus route would cross a bridge that was removed years ago.

Just a word of caution: even if this is routine in theory, the reality on the ground at this location had not matched our map for some time. Gladly, MFlamm ventured to fix it — I personally didn't feel comfortable doing so.

Juste pour être sûrs que nous avons tous bien compris:

(1) Vous ne souhaitez-pas fusionner les doublons de nodes mentionnés?

(2) Le problème que vous cherchez à régler est‑il lié à une requête sur un district du canton de Vaud retournant un immeuble situé à la frontière du district et une adresse qui n'est pas dans le district ?

(3) Avez‑vous besoin de précisions sur l'utilisation de addr:full ?

(4) Avez‑vous besoin de précisions sur les tags à appliquer à amenity=hotel ?

(5) Cherchez‑vous à exclure de vos résultats les tags que vous n'utilisez pas (par exemple addr2) ?

(6) En quoi cela concernerait‑il la communauté suisse ?

Petite précision: « French » et « Swiss » s'écrivent avec une majuscule.

Any idea why way/1500181260 was deleted? MFlamm work on this complex, messy and continuously changing location yesterday, presumably after a careful surveys he is known for.

Please provide a short summary about your edit.

È fatto. Prego

> Addr est sous "optional" non ?

Le libellé optional n'implique pas qu'il faille supprimer la donnée si elle existe ; il signifie simplement que le tag n'est pas requis pour créer un feature.

> Et comment structurer le texte ? Est-ce vraiment utile un texte non-structuré pour une adresse ?

Pour l'instant, la clé "addr:full" est prévue ainsi. addr:full=* peut vous aider pour une définition complète.

> Comme dit plus haut, il est probablement plus préférable que Nominatim supporte le cas de figure de lier un POI à plusieurs adresses qui se trouvent à l'intérieur de celui-ci. Cela réglerait votre problème tandis que le problème de frontière que j'ai mentionné plus haut ne serait pas affecté.

D'accord pour revisiter la prise en charge d'un POI lié à plusieurs adresses lorsque Nominatim le permettra ; en attendant, évitons de supprimer des données qui pourraient être utiles. Le problème semble venir de l'extraction/interprétation et ne devrait pas être masqué en modifiant les données sources.

> Justement je ne vois pas ce qui pourrait être utile

Répondre à ma question initiale.

Pour résumer: La suppression d'info n'améliorait pas vraiment la qualité et servait avant tout à modifier le résultat dans une recherche ponctuelle. Pour avoir plus d'info sur addr:full=* mieux vaut utiliser cette page-là.

Pour l'hôtel: way/102786964 ajouter addr:full et restaurer les tags structurés correspondants.

Pour les autres : consolider les entrées et leurs numéros d'accès, et compléter les tags pour qu'elles soient trouvables directement.

FRANCE:
node/1760386059
node/11082472553

SUISSE:
node/5710317910
node/13661915710

Après consolidation, on pourra supprimer 2 nodes redondants.

done with: https://bbl-dres.github.io/property-inventory/osm-height/

> Les adresses sont sur l'area de l'hôtel. C'est commun comme pratique.

tourism=hotel préconise de les inclure. On peut aussi utiliser les préfixes contact: si vous préférez.

> Quel est l'intérêt de addr:full dans ce cas de figure et quel serait le texte ?

ça permet d'avoir un texte lisible (en combinant addr:* et addr2:* ).

> quelqu'un a écrit

C'était probablement moi. Le fait que Nominatim n'utilise actuellement pas la seconde adresse ne doit pas empêcher de la saisir avec des clés claires.

> "Entrée côté suisse" peut être déduit si le point est positionné au bon endroit, non ?

Apparemment ça vous posait problème. On pourrait trouver une valeur plus claire pour "name".

Oh, please excuse. In the meantime, I had changed it to addr:suburb=Fornoli . I can update it to addr:hamlet=Fornoli if you want.

addr:suburb is frequently used:
https://taginfo.geofabrik.de/europe:italy/tags/addr:country=IT#combinations

Maybe addr:hamlet=Fornoli would work? See osm.wiki/IT:Key:addr:*#Etichette_usate_prevalentemente_in_paesi_che_utilizzano_lo_schema_borgo,_sobborgo,_sottodistretto,_distretto,_provincia

If we can figure out the correct key, I can fix them for you.

De quelle nature sont ces erreurs? Quels pays sont concernés?

What's the nature of these structural errors? What countries does this concern?

ça semble plus clair et les numéros sont correctement attribués pour ces entrées. Alex‑7 les avait renseignés de façon assez exhaustive et il est rarement nécessaire d'en supprimer. Je ne vois pas d'inconvénient à appliquer le numéro de l'entrée principale à l'ensemble de l'immeuble (peut-être 8-10 ne font qu'un?). A noter que SITG ne reflète pas forcément tous les numéros relevés sur place.

Moins sur Nominatim et OsmAnd (au moins au début). CoMaps: est-ce avant ou après vos modifications ? C'est un cas un peu particulier, donc qu'il n'ait pas beaucoup d'autres avec les mêmes tags n'est pas étonnant et ce n'est pas un problème en soi. Les hôtels ont l'adresse (aussi) sur le "feature" principal. Nous devrions probablement utiliser addr:full=* en plus d' addr2 . Peut‑être que l'hôtel sera mieux reconnu en inversant addr et addr2. Les entrées existaient déjà auparavant. Je pense qu'il est préférable de les nommer.

On ne le trouve plus en Suisse. Pourquoi ces modifications?