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?

Bonjour, merci pour ces mises à jour — elles améliorent la couverture des données. Peux-tu expliquer les modifications que tu as faites sur node/3670751278/history ? Comme le tag "addr:housenumber" désigne principalement l'entrée (ou la façade donnant sur une rue), je ne comprends pas l'utilité des suppressions. Si tu as une raison, peux-tu la préciser ? Sinon, je propose de restaurer les valeurs supprimées. Merci d'avance pour ton retour

addr:country=IT would be the value to use.
There are a few more with "Fornoli" instead of "IT". See https://overpass-turbo.eu/?w=%22addr%3Acountry%22%3D%22Fornoli%22+global&R

This now shows up on https://taginfo.openstreetmap.org/keys/addr%3Acountry#values fairly high.

If you need help fixing them, I can do it for you.

Merci pour les mises à jour. Une question sur way/79211056/history/16 : Pourquoi cette modification? alt_name=* est adapté pour ce type de changement, surtout si le nom est encore signalé et official_name=* a déjà été actualisé.

addr:country in nodes like way/321030967/history/4 would be addr:country=PL see https://overpass-turbo.eu/s/2nfa

addr:country should be addr:country=BR

J'ai corrigé et mis official_name:signed=no

Bonjour. C'est effectivement une erreur. Si le nom officiel change, on peut mettre à jour que official_name=* , pas plus. OpenStreetMap tente de refléter la réalité du terrain. Ce n'est pas le site officiel du canton.