Why don't you want to participate to the thread in community.openstreetmap.org?

> I don't see any editing of roofs in the changeset so the question seems off topic.

Could you please map the shape of the roof?

Discussion to be continued here: https://community.openstreetmap.org/t/how-to-map-a-swiss-building/143327

FPLC is based on EGID I guess. On my first argument, as said habi, there is no clear choice either we take the ground's perspective (it looks like a unique building and I guess people are speaking about a unique building in the spoken language) or the more formal way. As I said, I'm not totally opposed to using EGID (even if I'm not totally convinced we should totally match what the government does). Just tell me how to add a `roof:shape`.

@habi you are talking about local preferences. But I wonder if this shouldn't be discussed for the whole country in community.openstreetmap.org? Maybe it already has been? If I take the perspective of a newcomer, I think most of the people wouldn't know about EGID. It could be frustrating.

@habi Would it be a way to use `building:part` to combine both approaches?

"for example" is an important keyword in my sentence. The website is not from the owner if you look carefully but an association grouping multiple cooperative owner. People can be make typo. And this is not the source of my edit, just a simple way to share you some information (it's called the internet, I think).

Another way to look at it, is what we see on the ground (osm.wiki/Good_practice), I see a unique building personally.

Why do you have to be systematically so threating in your message?

Interesting, I'm ok to leave it as 3 buildings, but do you have any idea how to precise the roof:shape than? Do you use a relation or something else?

Sorry for the mistake about the wrong `addr:street`. I guess I made a wrong data manipulation at that time.

About the merge of the building, I'm still thinking that it should be a unique building way. 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/)
Secondly, the roof is a single part, as you can see from the picture. If it's not one building, I don't know how you tag it (I'm thinking about `building:part` but according to the wiki, it's made to split a building not reunite multiple ones) . If it's a single one `roof:shape=hipped` is quite appropriate, in my opinion.

Let me know if you have arguments against this change.

C'est dommage j'essaie de faire un pas dans votre direction et de comprendre ce qui pose problème.

Pourriez-vous réexpliquer le problème ?

Oui il s'agit d'un problème systématique, mais qui peut être résolu en utilisant des noeuds adresses dans bien des cas. Cela dit dans ce cas précis, la proposition d'Ionvia semble parfaitement indiquée, vous n'avez pas donné votre avis.
Vous n'êtes pas d'accord avec le fait d'utiliser des noeuds adresses pour résoudre ce genre de problème dans d'autres cas ? Quel serait votre solution dans d'autres cas ?

Vos points 1,3,4 ne sont pas clairs.

1. De quels doublons parlez-vous ? Chaque adresse à son noeud propre. L'hôtel est unique. Est-ce que j'ai loupé quelque chose ?

3. Je n'ai pas besoin de précision. Je vous ai déjà dit que je ne voyais pas vraiment l'intérêt car ce n'est pas une donnée parsable comme c'est écrit dans le wiki et que c'est très probablement une clé pas très utilisée par les systèmes de rendus. Donc ajoutez là si vous voulez, mais à quoi bon ?

Si vous voulez faire un sujet sur la partie française plutôt que suisse, c'est possible aussi. Le POI a bien à la fois une adresse française et suisse ou je ne comprends rien ?

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

Pourriez-vous re-préciser le problème ? Sur le sujet "community.openstreetmap.org" histoire de mieux comprendre votre problème.

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

Il s'agit d'une adresse suisse.

> (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 ?

Je pense que l'on ne se comprend pas depuis le début. 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.

Pouvez-vous répondre au sujet "community.openstreetmap.org", s'il vous-plaît ? Notamment la proposition d'Ionvia.

Je ne posterai plus de réponses sur ce groupe de modification.

https://community.openstreetmap.org/t/conflict-with-how-to-map-the-hotel-arbez-between-the-french-swiss-border/143133

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

Désolé, mais je ne peux pas vous laisser dire ça. La donnée n'est pas supprimée. Les adresses sont devenues des nœuds indépendants du chemin, mais tout en faisant partie du chemin en tant que géométrie. Comme déjà dit, c'est courant, pas interdit et surtout utile dans ce genre de cas.

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

Vous ne répondez absolument pas à ma question.

Je veux bien vous suivre si vous avez des arguments solides, mais ce n'est pas le cas alors essayez de me convaincre plutôt que de me prendre de haut.

Comme on ne trouve pas de terrain d'entente, il vaudrait la peine d'avoir l'avis de la communauté. Cela vaudrait la peine de créer un sujet sur community.openstreetmap.org.

Vous ignorez totalement le problème que je vous ai mentionné, comment le résolvez-vous avec votre solution ?

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

Addr est sous "optional" non ?

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

Oui mais par qui ? Et comment structurer le texte ? Est-ce vraiment utile un texte non-structuré pour une adresse ?

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

Vous vous contredisez. Votre but à la base était de faire en sorte que cela soit disponible dans la recherche. 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é.

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

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

> Moins sur Nominatim et OsmAnd (au moins au début). CoMaps: est-ce avant ou après vos modifications ?

Après mes modifications.

> Les hôtels ont l'adresse (aussi) sur le "feature" principal

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

> Nous devrions probablement utiliser addr:full=* en plus d' addr2

Quel est l'intérêt de addr:full dans ce cas de figure et quel serait le texte ? Je doute que cela soit pris en compte quelque part.

Concernant addr2, quelqu'un a écrit en janvier 2026 dans le wiki que ce n'est pas supporté par Nominatim. Et je vois qu'il y a une issue ouverte à ce sujet: https://github.com/osm-search/Nominatim/issues/1345

> Peut‑être que l'hôtel sera mieux reconnu en inversant addr et addr2

Cela va juste inverser la priorité de l'adresse.

> Les entrées existaient déjà auparavant. Je pense qu'il est préférable de les nommer.

Les entrées existaient sans avoir les bonnes clés d'entrées. Je ne suis pas totalement contre de nommer les entrées, mais est-ce vraiment nécessaire ? "Entrée côté suisse" peut être déduit si le point est positionné au bon endroit, non ?

Sur CoMaps, la recherche "arbez" donne deux fois l'hôtel. Une fois en Suisse, une fois en France.

Bonjour,

Quand vous dites, on ne le trouve plus en Suisse, est-ce que vous parlez de Nominatim ?
J'ai fait ces changements, car j'ai constaté que cela posait problème si je faisais une requête de type area sur overpass avec la région frontalière suisse et en voulant récupérer tous les adresses contenues dans cette région. Il n'est pas possible de savoir quelle adresse correspondant à la région avec le système que vous avez utilisé "addr, et addr2". En déplaçant les adresses dans chacune des frontières (ce qui semble également correspondre avec les différentes entrées), cela résout ce problème. Cela dit ce n'est peut-être pas la bonne approche. Il faudrait peut-être demander à Sarah Hoffmann ce qu'elle en pense et si le cas peut être résolu dans Nominatim.

Yep, thanks for the typo. It would be nice if you can do it, I'm quite busy this week and the following

Hi Habi,
I've added a couple of other buildings with this tag recently.

I'm not convinced that amenity=sheltered_housing is more suited to those type of building than the building key, but please try to convince me!

My thoughts: none of them have been accepted as a key or value. The only page that I could find is an abandoned proposal for amenity=sheltered_housing.
Looking at taginfo, building or residential = sheltered_housing seems slightly more popular (I added no more than 10 building with this tag myself).
In my opinion, it's very similar to building=dormitory (which is a de facto tag as well, but at least documented on the wiki). From what I understood, those are “normal” buildings but adapted for seniors or people with disabilities.

What do you think? Did I miss something?

Hi Mateusz,

I couldn't decide on a value while being in the street and I still cannot choose one. Maybe art or gift ? They do not seem to be a charity and they are selling various products from Equator: jewellery, craft, clothes and food.

What do you think ? Gift is probabéy the best.

Good catch ! Thanks habi

Best regards,
imagoiq