addr:state=DE would be addr:country=DE . For more see https://overpass-turbo.eu/s/2oEl

addr:state=DE would be addr:country=DE . For more see https://overpass-turbo.eu/s/2oEl

What's the meaning of this edit?

What's the connection between node/19630033/history/1 and version 2 of the node ?

What's the meaning of this edit?
What's the connection between version 1 and version 2 of the node node/17960327/history

It's a shop sign

As these are country-level changes, I think the geographical size is not unreasonable. It would be different for (small) features in each country.

I asked for the basis and a clear explanation for your edit; https://gchg.ch is what we got. If you feel challenged by questions about your mapping, I understand that can be frustrating, but being defensive isn't helpful. Saying "the internet" isn't a sufficiently specific source for an OSM edit.

FPLC has a nice overview of cooperatively owned properties and lists all three. I find the approach fairly consistent with other buildings in Geneva.

> 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".