One feature, one OSM element - POI in Gebäude als Node

Ich bin im Wiki gerade über folgenden Satz gestolpert:

https://wiki.openstreetmap.org/wiki/DE:Ein_Objekt,_ein_OSM-Element#Allgemeine_Regeln

Mein Stand war bisher, dass es eine zulässige Methode ist, ein POI als node in den Gebäude-way zu setzen, auch wenn der POI das gesamte Gebäude nutzt. Die One feature, one OSM element-Regel sehe ich nicht verletzt, da way und node jeweils zwei unterschiedliche Objekte beschreiben (Gebäude und POI). Das sich hierbei nicht um ein Objekt handelt, das zwangsläufig auch nur durch ein OSM-Objekt beschrieben werden sollte, sieht man daran, dass sich das Gebäude aus OSM-Sicht nicht verändert, wenn der POI wechselt.

Wie ist Eure Meinung dazu?

Halte ich nicht für Konsensfähig.

Ich habe mir angewöhnt POIs wirklich als POI also Node/Punkt zu erfassen. Das hat vielerlei Gründe. Das eine ist das nicht Tags der Gebäudebeschreibung mit Tags der POI beschreibung zusammen auf demselben Node/Way sind. Das hat den Vorteil das wenn ein POI weg ist man nur den Node löschen muss. Ich erlebe es immer wieder das dann bei der Tag durchsortiererei tags vergessen werden oder eben zu viele gelöscht werden.

Also ganz einfach Prozessökonomische Gründe das nicht zu tun.

Das andere ist das ich wenn ich einen POI “Aldi” mache exakt DIESER node angefahren wird im Routing und nicht der Punkt des Gebäudeoutlines der am nächsten an einer Straße liegt, wie z.b. die Hauszufahrt des Nachbarn dahinter. D.h. ich behalte die Kontrolle über das Routing(-Ziel)

Flo

Moin,

ich bin da ziemlich bei Dir (bzw. Euch, da Antwort vorher begonnen) - also für Trennung zwischen Gebäude und POI sowie für POI als node generell.
Aber mein Interesse beschränkt sich auch auf Navigierbarkeit mit deren Sonderwünschen - z.B. oft Verschiebung zum Eingang / Anlaufpunkt.
Andere mögen da andere Interessen haben, die auch die Ausdehnung benötigen.
Und dann kann das zu weiteren Exessen - ggf. Relationen - führen, wenn einem POI auch die Ausdehnung zugeordnet - sprich gemappt - werden soll …
Fragt sich also, ob man einen Teufel nicht mit Belzebub austreibt. :wink:

Grüße
Georg

1 Like

Hier in HB halten wir es auch meist so, dass wir Gebäude und deren Inhalt voneinander getrennt halten. Es gibt mittlerweile eine Menge Gebäudedaten (3D-Tags, Denkmalschutz etc) und die Daten der POIs werden auch nicht weniger. Das wird für Neu-Mapper schnell unübersichtlich und erhöht die Fehlerquote beim Editieren.

tldr: Ich stimme meinen Vorrednern zu :slight_smile:

Moin, ich habe angefangen, nach der von OSM_RogerWilco zitierten Regel

Geschäfte zu erfassen, auch wenn ich selber diese Regel nicht besonders elegant finde. Die Trennung in Gebäude und Geschäft ist - ungeachtet der angesprochenen Vorteile beim Routing - m.E. schon von der Logik her sinnvoller, da es sich um 2 unterschiedliche Objekte handelt. Ein Verstoß gegen die Regel “Ein Objekt = ein OSM-Element” entsteht m.E. auch nur dann, wenn die Attribute des Geschäftes bzw. POI zweifach erfasst werden, einmal auf dem Gebäude und einmal auf einem zusätzlichen Node. Aber als Neuling schaut man halt doch erst mal ins Wiki …

Ich werde das Erfassen weiterer Geschäfte vorerst zurückstellen und die Diskussion beobachten. Wenn es diesbezüglich einen Konsens geben sollte, wäre es sicher sinnvoll, den entsprechenden Eintrag im Wiki zu korrigieren :roll_eyes:.

Im englischen Wiki heisst es an dieser Stelle:

da steht zwar nicht "should be tagged, sondern “can be tagged”, macht in der Praxis aber m.E. nicht viel Unterschied.

ich finde einen Node innerhalb einer Fläche besser als in einem einzigen Objekt (also einem way) mehrere Dinge zu vermischen, weil das dann dazu führt, dass es irgendwann falsch wird (durch Hinzufügen von weiteren tags, die nicht für alles sondern nur für Teilaspekte gelten). Noch besser ist eine Fläche innerhalb der Fläche bzw. überlappend, aber bei kleineren Sachen ist mir das auch zu viel Arbeit, und auch weniger offensichtlich für nachfolgende Mapper. Je mehr “Dinge innerhalb von Dingen” man abbilden will, um so mehr hilft es, wenn die “Container” keine nodes sondern Polygone sind.

Na das ist ja so der Klassiker im Deutschen Wiki. Ich halte das mittlerweile für einfach großflächigen Unsinn. In Deutschland editiert da jeder ohne Konsens oder Diskussion und versucht seine Partikularinteressen oder Missverständnisse durchzudrücken. Dazu wird das eben nicht markiert was aus dem Englischen original durch Übersetzung kommt und was deutsche Sonderlocken sind.

“should be tagged” und “can be tagged” ist schon ein großer Unterschied.

Das eine ist “sollte” und das andere ist “kann”.

Und ja - Man KANN das technisch auf demselben Objekt machen, das ist aber wie ja hier in der Diskussion klar wird zumeist nicht optimale Lösung.

Flo

es wird halt oft so gemacht (building gibt es schon, und jemand hängt ein paar feature tags dran, shop=supermarket oder so). Von daher ist es normal, dass das Wiki schreibt man könne es so tun, kann man ja. Sollte man aber eher nicht wenn man die Muße hat, es besser zu machen, dann sollte man es vielmehr anders machen.

Ja, das sehe ich auch so und bevorzuge die Trennung zwischen Gebäude und Geschäft. Auch weil der Geschäfts-/Ladenname in der Regel nicht der Gebäudename ist. Man könnte auch darüber philosophieren, ob “der POI” nicht nur den Raum innerhalb des Gebäudes nutzt :wink: (Insbesondere, wenn das nur gemietet ist.)

Yo, das habe ich in kürzester Zeit auch schon mehrfach festgestellt und schaue daher im Zweifelsfall immer in die englische Version.

Ist schon klar, aber auch “can be tagged” geht in die Richtung “kann jeder so machen, wenn er will”. Besser wäre m.E. die Richtung mit “should be avoided to tag … to the building itself” vorzugeben, das wäre dann immer noch kein explizites “nein”, aber für den noch nicht so sattelfesten Neumapper wie mich eine deutliche Richtungsansage. Das wollte ich mit “macht in der Praxis keinen großen Unterschied” zum Ausdruck bringen.

Anyhow, für mich ist die Vorgehensweise “Einrichtung separat im Gebäude mappen” eindeutig die sauberere Lösung.

Danke für Eure Meinungen. Der Text steht ja nicht irgendwo, sondern auf der Seite, die die One feuture, one OSM element-Regel beschreibt.

Folgender Satz im de-Wiki taucht so auch nicht im en-Wiki auf:

Das englische Wiki sagt:

Ich denke die deutsche Übersetzung muss dringend angepasst werden.

Das Stand 2015 auch noch im englische Wiki und war damals gang und gäbe.

https://wiki.openstreetmap.org/w/index.php?title=One_feature,_one_OSM_element&oldid=1246102

Es wurde im Juli 2019 von Jeisenbe gelöscht.

So ändert sich halt vieles still und heimlich.

Alles hat seine Vor- und Nachteile je nach dem was man mit den Daten machen möchte und für wenn das Ergebnis abzielt. Da OSM offen für viele Anwendungsfälle ist kann man das pauschal nicht so einfach beantworten.

Also Mapper ziehe ich eh vor das die Daten einfach zu bearbeiten und zu warten sind. Was öfter auch ein Punkt ist :wink:

Gruß Miche

ich vermute eher, dass Jeisenbe das vor dem löschen diskutiert hat.

Eben. Mir geht es nicht um das entweder oder, sondern ob beide Varianten “zulässig” sind. Aktuell ist die Aussage, dass die eine Variante eindeutig gegen OSM-Prinzipien verstößt und der Artikel ruft dazu auf, dass man solche POI-Nodes löscht und die Daten an den Gebäude-way verschiebt. Es wird sogar als zentrales Beispiel für die Verletzung der One feature, one OSM element-Regel verwendet. Das halte ich nicht für richtig.

Und diese Grundsätze werden gerne verlinkt und vor allem neuen Mitwirkenden als Pflichtlektüre genannt.

+1

Die Formulierung in Good Practice (https://wiki.openstreetmap.org/wiki/DE:Good_practice) ist besser, muss aber auch richtig verstanden werden:

Worauf es ankommt und was die Regel meint, habe ich mal fett hervorgehoben.
Ausführlicher formuliert heißt das, man soll ein Geschäft nicht doppelt am Polygon und als Poi eintragen. Das heißt abet nicht, dass eine Variante grundsätzlich zu bevorzugen sein und die andere Variante geändert werden sollte.
Man kann sehr wohl regelkonform die Ansicht vertreten, dass das eine Objekt das Gebäude ist, und das andere Objekt das Geschäft darinnen.
Eine Regelverletzung liegt jedoch dann vor, wenn ich die Adresse sowohl am Gebäude als auch am Poi/Geschäft mappe. Dieses Problem hat man aber auch, wenn man mehrere Geschäfte an der gleichen Adresse hat.

So ist es m.E. völlig korrekt beschrieben … nur wenn beide Objekte dieselben Attribute haben, steht das im Widerspruch zu der OSM Grundregel. Wenn area und point aber richtigerweise mit unterschiedlichen Attributen getaggt sind, ist eben das nicht der Fall. Das geht so aus der deutschen Version eindeutig nicht hervor, und darauf bin sicher nicht nur ich hereingefallen …:(.

Das ist so, aber hier kann ich die Vorteile beim taggen aller Eigenschaften auf das Gebäude eigentlich nicht erkennen, außer das es vielleicht bei der Neuerfassung ein bisschen weniger Arbeit macht, bei späteren Änderungen dafür aber mehr.

Dieser Meinung schließe ich mich an.

Dass es hier einen permanenten Evolutionsprozess gibt, ist m.E. völlig normal und im real life auch nicht anders. Ein früher mal ganz wesentlicher Beschränkungsgrund waren z.B. die Serverkapazitäten. Ich weiß von einer Datenbankprogrammierung in den 90er Jahren, dass da um jedes zusätzliche Attribut genau aus diesem Grund heiße Diskussionen geführt wurden. Das ist heute nicht mehr relevant, wirkt aber vielleicht bei der einen oder anderen Entscheidung in den Anfangsjahren von OSM noch nach.

Youah, aber area ist nicht gleich area. Ein Spielplatz ist ein Spielplatz und beinhaltet nicht gleichzeitig einen Parkplatz. Wenn das irgendwann ein Parkplatz werden soll, verschwindet der Spielplatz damit zwangsläufig. Da passt das mit dem taggen der Eigenschaften auf die Area schonl.

Bei Gebäuden ist das anders. Wenn da eine Einrichtung wechselt, bleibt das Gebäude erst mal unverändert erhalten.

Darin sehe ich keinen Regelverstoß. Wenn sich in einer Mall 3 Geschäfte für Damenmode befinden, dann habe ich 3 Nodes mit vielen identischen Attributen, und alle haben dieselbe Addresse wie das Gebäude. Das entspricht genau der physischen Präsenz und ist damit m.E. völlig ok.

+1, das kommt immer wieder hoch, dass es Adressen angeblich nur einmal geben kann, aber wir sind ja nicht das Amt das Adressen vergibt. Die Adressen werden Grundstücken zugeteilt, und wenn es dort mehrere Dinge gibt dann haben die alle dieselben Adressdaten. Problemlos

das Wort “Attribut” kann man in diesem Kontext auch falsch verstehen, weil wir unsere tags informell unterteilen in “Haupttags” (Feature tags, amenity, shop etc.) und Eigenschaften (Attribute) die zusätzlich getaggt werden, z. B. name, operator, height, addr:*, wikidata, start_date, material, etc.

Nur das genau gleiche Objekt soll nur einmal vorkommen, aber es kann durchaus am selben Ort mehre Objekte mit demselben wikidata link geben, oder mit demselben Namen, …