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

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, …

z.B. aus einem Tagging kann man oft nicht daraus schließen… wie viel Fläche/Größe das Objekt einnimmt. Also ist das z.B. ein großer Spielplatz oder ein kleiner Spielplatz. Und das ist nur ein Beispiel von vielen. große/kleine Firma…

Man kann daraus die Bedeutung anhand der Größe schließen… was z.B. unter andern beim rendern von großer Bedeutung ist.

Gruß Miche

das ist nur ein Argument für eine Fläche, aber nicht dafür, das Gebäude mit der Firma (etc.) zu vermischen

Doch gerade deswegen…

Also hier im Topic geht es um Einrichtungen innerhalb von Gebäuden. Spielplätze, Sportanlage, Parkplätze sind ein ganz anderes Thema, da sehe ich persönlich kein Problem mit dem Taggen auf die area, wie schon zuvor angemerkt.

Einen Rückschluß auf die Bedeutung einer Firma oder Einrichtung daraus abzuleiten, dass die Firma/Einrichtung direkt auf die Gebäudearea getaggt ist, halte ich jetzt nicht für wirklich plausibel. Selbst wenn man das so annimmt, welchen Unterschied würde das beim rendern machen?

Was glaube ich gemeint ist, wenn man ein Polygon taggt ergibt sich schonmal, wie groß das Objekt ist und wieviel Fläche es bedeckt. Wenn etwas eine große Fläche auf der Karte in einem bestimmten Maßstab einnimmt wird man normalerweise wissen wollen, was es ist, also andersrum wird man als Kartenersteller wird man das beschriften wollen.

Ok, danke, leuchtet mir ein. Aber muss man dafür die Shopattribute auf die area taggen? Hier ein fertig gerendertes Beispiel:

https://www.openstreetmap.org/query?lat=50.96971&lon=9.79544#map=19/50.96957/9.79518

Rechts der Aldi, ein node in der Gebäudeaerea - ein Gebäude, ein Laden, da bleiben doch keine Fragen offen. Wenn ich jetzt noch die Adresse auf einen separaten node am Gebäudeeingang legen würde, würde auch der robocab punktgenau dahin finden.

Links die Mini-Mall “das be!”, viele nodes in einer Gebäudearea, auch alles klar. Man sieht auf einen Blick, was Sache ist, oder nicht?

Ich kann bei diesem Vorgehen keine Nachteile erkennen.

wenn in deiner minimall nun 2 große shops sind, die alleine schon 2 drittel füllen, und dazu noch 20 kleine, und alle sind als Nodes gemappt, dann hast du 22 shops die erstmal alle gleichwertig aussehen, wären die Flächen gemappt würde man selbst ohne Ansehen der Flächen schon ein passables Rendering bekommen weil die großen shops genug Abstand haben :wink:
Wenn man die Flächen berücksichtigt kann man sich “aus der Entfernung” auf die großen Dinge beschränken (sofern einen “alles gleich viel interessiert”)

Yo, ich bin da absolut bei Dir, aber das Problem löst man doch nicht, indem man einen der großen Shops auf das Gebäude taggt. Wenn man es so genau darstellen will, muss man die shops als area im Gebäude mappen, oder nicht? Und hier ging es ja um die Frage “ein shop, ein building” also analog ALDI …

Dann sind diese Flächen aber nicht identisch mit dem Gebäudeumriss …

Vielleicht liegt da auch ein Missverständnis vor.
Um auf die Größe schließen zu können ist nur ein Argument dafür, einen Poi als Fläche zu mappen. Das ist aber kein Argument für die Regel “one feature, one OSM element” - das besagt eigentlich nur, dass eine Eintragung nicht doppelt vorgenommen werden soll, als Fläche und als Poi. Und dabei das Gebäude als Fläche zu “missbrauchen”. Es gibt durchaus auch Argumente, eine Firma, einen Shop oder was auch immer, getrennt vom Gebäude zu halten - das erleichtert einen Umzug des Unternehmens ungemein, das Gebäude zieht ja nicht mit um.

Ja, dafür gäbe es ja Indoor-Mapping :wink: Wie z.B. hier: https://openlevelup.net/?l=0#19/52.13056/11.63031

+1 Es gibt bisher keine Festlegung, dass z.B. Geschäfte nur als node eingetragen werden sollen. Ich kennzeichne einfache Geschäfte idR als Node, Einrichtungen wie Supermärkte vorrangig ans Gebäude und bei großen Firmen das Firmengelände als area anstatt eines Nodes. Aber alles hat seine Vor- und Nachteile. Deswegen ist das eine nicht unbedingt besser oder schlechter.

+1
Beim Node innerhalb des Gebäudeumrisses ist ein kleiner Nachteil, dass Umriss und Node datentechnisch nicht verbunden sind.
Wenn man also Gebäude verschiebt und nicht aufpasst, landet der Node u.U. im Nachbargebäude.
Wenn das Gebäude speziell für den Zweck gebaut wurde (typisch: Hotel), ist das Tagging mMn besser am Umriss aufgehoben.

Yo, das ist mal ein echtes Argument, aber mal ehrlich, wie oft passiert einem das, wenn man halbwegs sorgfältig arbeitet? Und der Aufwand, den Node mit der Maus dem Gebäude hinterherzuschieben, ist auch überschaubar.

Ich denke, es ist schon aus Gründen einer einheitlichen und nachvollziehbaren Datenstruktur besser, einheitlich zu verfahren, also entweder grundsätzlich Einrichtungen an das Gebäude zu taggen oder eben nicht, unabhängig davon, ob eine einzelne Einrichtung das gesamte Gebäude belegt. Selbst, wenn der Fall 1 Einrichtung = 1 Gebäude aktuell gegeben ist, kann das morgen schon anders sein.

Auch zweckgebundene Gebäude sind nicht davor gefeit, aufgeteilt zu werden. Hier gibt’s z.B. ein Rathaus, da wurden aus Geldmangel Räume an einen Laden und als Büro vermietet. Ehemalige Hotelbauten, die heute teils Wohnraum und teils Ferienwohnung sind u.s.w. Wenn man von Anfang an das Bauwerk von der Einrichtung trennt, bleibt die Datenstruktur in allen Fällen immer einheitlich.

sie sind wohl datentechnisch verbunden (räumlich), allerdings ist das weniger “fest” und vielleicht nicht jedem sofort erkenntlich (insbesondere wenn man mit Filtern Dinge ausblendet oder der Stil im Editor die tags auf einem Objekt nicht darstellt gibt es das Problem, dass das Konstrukt ggf. versehentlich kaputt geht). Bisher gibt es gegen solche Verschiebungsprobleme noch keine Sicherheitsgurte, aber der Editor könnte z.B. durchaus anmerken dass man ein Adresspolygon so verändert hat, dass Dinge jetzt draußen sind die vorher drinnen waren, und ob man das wirklich wollte.

In solchen Fällen ist es vermutlich seltener, dass es schon bei den Hauptattributen zum offenen Konflikt kommt (z.B. unterschiedliche Namen für das Gebäude und das Hotel), aber grundsätzlich sollten wir m.E. eher ins Wiki schreiben, dass auch bei Gebäuden gilt dass unterschiedliche Dinge als eigene Objekte repräsentiert werden sollten, auch wenn es (m.E. temporär) real auch anders anzutreffen ist. Bei Hotels ist die Fläche z.B. sehr oft größer als nur das Gebäude, weil der Innenhof, der Garten, der Parkplatz, die Terrasse etc. auch dazugehören (je nach Lage natürlich).

Eigener Umriss (auch z.B. multipolygon mit nur einem outer member) ja gerne (besser als nodes), Mischen von unterschiedlichen Dingen (aus Sicht der OSM tags) bitte vermeiden.