ja, es gibt unterschiedliche Arten das abzubilden, aber sie sind nicht alle gleich gut. Prinzipiell ist es sauberer, für unterschiedliche Dinge auch unterschiedliche Objekte in OSM zu haben, d.h. die shops getrennt von den Gebäuden zu mappen, zB. als multipolygon relation oder überlappenden way, wenn man ein Polygon mappen will, oder als node innerhalb des building polygons, wenn man auf die Größeninformation verzichten will.
Wenn man das nicht macht wird es unklar, worauf sich die tags beziehen (ist der name oder das start_date das des shops oder des Bauwerks? etc).
Trotzdem ist es etablierte Praxis, als Abkürzung sozusagen, diese Dinge zu vermischen und es den Auswertern zu überlassen, die Zuordnung der tags zu erraten (weil die meisten Bauwerke keine Eigennamen haben und kaum jemand start_date taggt, z.B.), zumal in einfachen Fällen (wenige tags gesetzt und daher wenig Verwechslungsgefahr) und vorläufig. Das ändert aber nichts daran dass eine saubere Trennung besser ist und sich problemloser erweitern lässt.
Von daher ist es bei der Ersterfassung jedem selbst überlassen, wie er die Dinge abbildet, bei Änderungen würde ich dagegen nur diejenigen akzeptieren, die eine Verbesserung bewirken, also nicht von area zu node konvertieren (verliert Flächeninfo) oder von getrennt zu gemischt, sondern nur anders rum
Da ging es im Grunde genau um dieses Thema und die Antwort ist: Es besteht eine Beziehung zwischen Node und Gebäude durch “Geocoding”. Es reicht also, wenn der Node einfach innerhalb des (geschlossenen) Gebäude-Ways ist.
Eine Ausnahme könnte ich mir z.B. bei einem Supermarkt vorstellen, der komplett ein eigenes Gebäude hat, ohne dass es da noch andere Shops oder Bewohner gibt.
Und da auch nicht unbedingt, weil meiner bescheidenen Meinung nach auch der Parkplatz zum Supermarkt gehört. Wenn man nur abbilden wollte, was zum “Einkaufsbereich” gehöre, dann würde wiederum im Gebäude die Sozialräume und das Lager nicht dazugehören (Nicht ganz ernst gemeint! => KISS)