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.
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 (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.
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
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.
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.
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.
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.
(Insbesondere, wenn das nur gemietet ist.)