Ich habe gerade eine Firma ein zweites mal gemappt node & building. Auf der Suche im Wiki, was der korrekte (bessere) Weg ist musste ich feststellen, dass es nicht sooo einfach ist
Unter Gebäude steht sinngemäß wenn gesamtes Gebäude eine Firma, dann am Gebäude, sonst node.
Das halte ich für das Mappen in Gewerbe-/Industriegebieten für problematisch, da die Übersicht fehlt und wie oben beschrieben schnell eine Dopplung entsteht.
Auch ist es für mich nicht 100 % konsistent.
Und es ist auch nur im deutschen Wiki beschrieben.
Also wollte ich primär nodes nutzen.
Am Firmen Node soll (verständlicher Weise) auch die Adresse eingetragen werden. Andererseits habe ich gelesen, dass - ebenfalls für mich verständlich - eine Adresse nur einmal erfasst werden soll. Gab es da nicht einmal einen abweichenden Tag zu addr?
Sicher ist das Thema schon öfter aufgekommen, ich habe über die SuFu aber nicht den passenden Beitrag gefunden. Ggf. bitte verlinken. DANKE
P.S.: Die Dopplung wird wieder rückgängig gemacht!
P.P.S: Auf der Suche nach einem guten Beispiel, bin ich hierauf gestoßen. Dort gibt es auf kleinstem Raum noch mehr Varianten. Unter anderem wurde ein Gebäude als mehrere erfasst und jeweils eine Firma angehängt. KEIN building:part, sondern wirklich einzelne Gebäude!
POI Nodes kannst Du immer verwenden. Egal ob das POI alleine im Gebäude ist oder nicht. POI Daten und Gebäudedaten zu trennen macht allgemein Sinn. Ich ergänze immer die Adressdaten bei POIs. Allerdings gibt es da auch andere Meinungen (unnötige Redundanz und die Adressdaten können vom Gebäude ermittelt werden).
Ich halte das auch für die bessere Lösung, auch wenn ich in der Vergangenheit manchmal schon Firmeninfos direkt an das Gebäude getaggt habe, wenn es sich um firmenspezifische Gebäude (wie zum Beispiel die typischen Bauten eines Discounters) handelt.
Trotzdem sind Gebäude und Firma m.E. 2 unterschiedliche Objekte und wenn die Firma pleite geht oder (im Falle einer Firmenkette) beschließt, eine Filiale dicht zu machen, wird das Gebäude im Normalfall ja nicht abgerissen, sondern verkauft oder an eine andere Firma vermietet. Um das in OSM realitätsgetreu abzubilden, müssen Gebäude und Firma ebenfalls voneinander getrennt erfasst werden. Und wenn sich mehrere Firmen ein Gebäude teilen, geht es ohnehin nur mit Nodes, die im Gebäude platziert werden.
Auch im Bezug auf die Adressdaten stimme ich @OSM_RogerWilco zu: die gehören sowohl an das Gebäude als auch an die darin befindlichen Firmen-Nodes.
Am Firmen Node soll (verständlicher Weise) auch die Adresse eingetragen werden.
sehe ich auch so, teilweise wird das aber auch abgelehnt, wenn sich die Adresse bereits aus einem umschließenden Polygon ergibt.
Andererseits habe ich gelesen, dass - ebenfalls für mich verständlich - eine Adresse nur einmal erfasst werden soll.
wo hast du das gelesen? M.E. ist das eine Verwirrung die daher kommt, dass jede Adresse (amtlich) nur einmal vergeben werden sollte. Es kann aber trotzdem unendlich viele Dinge mit derselben Adresse geben (zumindest wenn man bei der Hausnummer aufhört und nicht noch Stockwerke, Haustür-/bzw. Wohnungnummern, etc. berücksichtigt). Wenn es mehrere POIs im selben Haus / auf demselben Grundstück gibt, werden die in Deutschland oft dieselbe Adresse haben.
Das wird aber von manchen QA-Tools als “duplicate address” angezeigt.
Daher der Ansatz, die Adresse nur auf dem Hausumring und nicht auf den POIs innerhalb einzutragen, da die Adresse ja geometrisch ermittelt werden könne. Für Otto Normaluser ist aber die Adresse direkt am POI weitaus besser greifbar.
Das ist im Prinzip die altbekannte Problematik von Redundanzen in OSM mit ihren spezifischen Vor- und Nachteilen.
Das würde ich auch nicht als Entscheidungskriterium nehmen. Die zeigen ja alle nur mögliche Fehler an. Osmose ist da für meinen Geschmack teilweise etwas merkwürdig.
Das ist es auch nicht, nur eine Erklärung, weshalb es manche stört.
Abgesehen davon gibt es gute Gründe, weshalb Redundanzen in Datenbanken allgemein verpönt sind, aber auch gute Gründe, weshalb sie in OSM hilfreich sein können.
OK, ich hatte befürchtet, dass es doch nicht so einfach ist
Da ich selbst schon mit relationalen Datenbanken gearbeitet habe, kann ich gut nachvollziehen, dass die Normalisierung (keine mehrfachen Angaben) erhebliche Vorteile bietet.
Beispielsweise wenn ein Ortsname geändert wird (ist selten, aber bei uns in der Gegend schon vorgekommen). Einmal am Ort geändert, und schon passen alle in der Fläche enthaltenen wieder.
Andererseits ist die Zuordnung zu Straßen insbesondere bei Kreuzungen teils nicht eindeutig. Da OSM nicht relational aufgebaut ist fängt es (in meinem Verständnis) hier schon an problematisch zu werden.
Wie komplex die passenden Abfragen sind, kann ich nicht nachvollziehen.
Meine Interpretation(!): Alle Flächeninhalte - angefangen von Land bis Gemeinde - sollten gut zu ermitteln sein. Straßen definitiv nicht in allen Fällen.
Damit müsste man konsequenter Weise auch durchweg auf addr:country=* und addr:city=* in Adressen verzichten.
Wenn das irgendwann einmal eindeutiger Konsens ist, kann man die Einträge ja automatisiert entfernen. Ob ich das noch erlebe?
Oh ja, sa können wir in OSM ein Liedchen von singen, dass wir es manchmal akzeptieren müssen, dass es zu manchen Themen einfach keinen eindeutigen Konsens gibt und nie geben wird
(ich sage nicht, dass das nicht manchmal auch ganz gut so ist).
Ich halte das auch für die bessere Lösung, auch wenn ich in der Vergangenheit manchmal schon Firmeninfos direkt an das Gebäude getaggt habe, wenn es sich um firmenspezifische Gebäude (wie zum Beispiel die typischen Bauten eines Discounters) handelt.