Das Gebäude ist ein Hotel → in diesem ist eine öffentliche Gaststätte. building=hotel mit name, phone, website, addr:… und Gaststätte ist ein node mit phone, website, … (falls abweichend) - In dem Hotel gibt es noch einen Frisör … ( noch ein POI)
Moin Geri,
Du zeigst mit Deinem Beispiel genau auf, warum die gängige Praxis Käse ist. Das Gebäude ist ein Gebäude und das hat ganz andere Attribute, die nicht vermischt werden sollten. Darin sind die POI, die sich sogar verorten lassen. Über den Stuss mit building oder area gleich yes oder sonstwas werde ich mich an dieser Stelle nicht weiter aufregen, das hat sich mit einer neuen API hoffentlich auch erledigt.
LG,
-moenk
Für unausgereifte Anwendungen, die nur mit Punkten umgehen können, besteht ja die Möglichkeit, die Umwandlung Weg/Relation → Knoten nach dem Herunterzuladen durchzuführen. osmconvert ermöglicht das schon out-of-the-box mit der Option --all-to-nodes; und ich würde mich nicht wundern, wenn mittelfristig auch die eierlegende Wollmilchsau genannt Overpass API ähnliches anbieten würde. Ich sehe nicht, warum OSM seine Abbildung der Realität kastrieren sollte, um einigen unbedarften Nutzern zwei Zeilen Code zu ersparen.
Oli-Wan,
es geht doch erstmal nicht um Anwendungen, sondern um ein sauberes Datenmodell. Mir kommts auch gleich wieder hoch wenn ich die Arroganz in Deinem Zeilen da herauslese. Sollen die anderen doch sehen wie sie mit unserem Murks klar kommen, wir machen das so wie wir das praktisch finden, gibt doch hier ein Tool und da eine Funktion, alles ganz einfach, sind doch nur zwei Zeilen Code, Pipifax, wir sind genial und ihr seid alle Pfuscher - so einfach geht das nicht!
Das ist aber auch nicht die Frage. Ich finde dass die wirtschaftliche Nutzung des Gebäudes nichts in seinen Attributen zu suchen haben muss. Vermehrt wird das aber bevorzugt so gemappt und auch als korrekt propagiert.
LG,
-moenk
Geht es nun um Anwendungen oder nicht?
Wer unsere Daten nutzen will, kommt nicht umhin, sich mit dem verwendeten Datenmodell zu beschäftigen. Und auch mit der Tatsache, daß die Erfassungsarten ebenso wie die Datenqualität nun einmal sehr inhomogen sind. In der Regel wird er auch nicht daran vorbeikommen, die Daten für seine Zwecke aufzubereiten.
Bei einem Gebäude, das ausschließlich ein Restaurant, eine Bank, einen Supermarkt, ein Hotel, eine Hochschuleinrichtung, eine Autowerkstatt, … beherbergt, ist das Gebäude für mich synonym mit dem jeweiligen Objekt. Wollte man Nutzung und Gebäude trennen, dürfte man konsequenterweise auch keine - postalischen! - Adressen an Gebäude taggen (siehe aktuelle Inkarnation des ewigen Themas im Nachbarfaden) - schließlich schreibt man ja den Bewohnern bzw. dem dort ansässigen Unternehmen einen Brief, nicht dem Gebäude selbst.
Hier ist zu beachten, das gleichzeitig alle Wege und Relationen entfernt werden.
Möglicherweise ist dies nicht das, was man möchte …
Ansonsten halte ich es für essentiell wichtig, daß Objekte nicht doppelt erfaßt werden / sind.
Also sowohl an einem Way (Polygon) als auch an einem Node.
Gruß Klaus
Oli-wan,
genau so isses. Das Gebäude hat andere Attribute, wie Höhe, Anzahl der Stockwerke, Dach, vieles mehr. Mit der Hausnummer bin ich auch als Punkt einverstanden, ein Gebäude kann auch mehrere haben. Hier sollte vielleicht auch eine klare Vorgabe her. Das bringt uns aber etwas vom Thema ab.
Ich halte immer noch die Zuweisung der POI-Attribute an das Gebäude für falsch. Das ändert nichts daran, dass ich die Vorgehensweise anderer akzeptiere, aber das OSM-Datenmodell für dringend reformbedürftig halte. Es geht um saubere Datenstrukturen, der durch die Crowd entstandene Wildwuchs wird für mich immer unerträglicher. Aber sonst scheint sich um sowas im Forum kaum jemand Gedanken zu machen. Alle Argumente gehen für mich in die Richtung “weil man das so machen kann”.
LG,
-moenk
Moin Klaus,
am besten nur als POI 
Doppelt passiert, wir wissen alle warum, und das wird immer wieder passieren.
Danke an dieser Stelle für das Paket zum Jahresende!
LG,
-moenk
Auch, wenn ich schon in wenigen Fällen POIs an Flächen gepappt habe, stimme ich moenk voll zu. POIs gehören in einen einzelnen Node. Mir ist gerade kein Beispiel eingefallen, wo es Vorteile bringt, das nicht zu tun. Es ist einfacher auswertbar und würde sich auch einfacher pflegen lassen. Es geht zwar auch mit Flächen, die Auswertung wird aber verkompliziert - auch wenn es nur eine Zeile Code oder nur ein einzelner Buchstabe im Code ist. Wenn es einfacher geht, weshalb dann nicht einfacher machen?
Ich werde in Zukunft POIs als einzelne nodes taggen.
Dancingman,
danke für Deine Unterstützung - “ganz einfach” isses übrigens gar nicht, nur in bestimmten Szenarien lässt sich die Auswertung mit relativ wenig Aufwand machen. Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.
LG,
-moenk
@moenk: Machen wir das mal anders herum. Mit Polygonen hast du die Möglichkeit, dem Restaurant eine Fläche zu geben. Wenn wir jetzt komplett auf Punkte umsteigen würden, wie würdest du dann irgendwann (man weiß ja nie, vielleicht bekommen wir ja irgendwann Pläne von Gebäuden auf einem Level 20 oder so) die Fläche angeben?
Generell verstehe ich dein Anliegen vom Trennen von Objekt und Nutzung. Kann ich komplett nachvollziehen. Aber wenn das ganze Gebäude ein ALDI ist, die auch die Fläche ein ALDI, also gebe ich der Fläche aktuell den Namen ALDI. Auch wenn es sicherlich nicht so 100% sauber ist. Ich finde es aktuell immernoch besser, die Nutzungsfläche zu taggen, als nur vage da einen Punkt reinzusetzen. Man kann das Tagging auch anders interpretieren: Nicht das building = yes bekommt ein Attribut amenity = supermarket, sondern der Supermarkt ist eben überdacht, also der amenity bekommt als Attribut das building-Tag. Ähnlich wie bei Haltestellen und shelter. Oder man interpretiert es als nebeneinander: Da gibt es ein building und ein amenity auf der Fläche. In beiden Interpretationen ist nichts, was falsch ist… Da ist eher die Landnutzung spezifiziert: Ein überdachter Supermarkt… Finde ich nix schlimmes dran.
Wie gesagt, ich verstehe deinen Einwand, aber er ist meiner Meinung doch sehr engstirnig und einseitig betrachtet. Mir ist es lieb, die Fläche zu erhalten. Und dafür interpretiere ich die Daten, dass es passt - oder besser: Nicht so, dass es nicht passt. Ist irgendwie klar, was ich versuche zu sagen? 
Hallo,
Ich wäre auch für eine Trennung, denn dieses Erfassungssystem ist nicht konsequent
Befindet sich nur ein POI im Gebäude, dann ans Gebäude, sind es mehrere dann an einen Node, nicht gut 
Warum nicht auch bei einem POI extra an einen Node? Einfach immer, wenn ein POI vorhanden ist, dann an einen extra Node, das würde ich konsequente Umsetzung nennen.
Das gleich sehe ich bei Adressen. Befindet sich in einem Gebäude nur eine Adresse, ans Gebäude, sind es mehrere dann wird an Nodes getaggt. Das ist das gleiche Tagging wie bei den POIs, nicht gut.
Auch hier würde das generelle Erfassen an Nodes eine klare Struktur schaffen und eine einheitliche Erfassung leichter machen. Nicht einmal so und dass wieder so…
Ich finde es einfach logischer und klarer und auch für Neulinge leichter umzusetzen.
Hmm, bei Adressen gibt es die Möglichkeit, die Gebäude zu splitten. Das wurde oft diskutiert (erst vor kurzem hier http://forum.openstreetmap.org/viewtopic.php?id=19376)). Ich hab früher komplett Nodes an die Stelle des Eingangs gehangen. Dann wurde das von jemandem umgemappt und hier wurde das Vorgehen diskutiert und für sinnvoll befunden. Nun mappe ich unterteilte Gebäude. Auch wenn ich damit nach wie vor nicht konform gehe, weil ein Gebäude eben nicht 3 Gebäude sind, sondern 3 Eingänge mit 3 Adressen, mache ich es so. Bei POIs ist es doch auch so möglich. Und vermutlich sogar sinnvoller, da Geschäfte wirklich räumlich voneinander getrennt sind. Insofern kann man durchaus immer auf POIs verzichten. Man muss also nicht in die eine, sondern kann auch in die andere Richtung gehen.
Die meisten POI (Points/Polygons Of Interest) haben nun mal eine räumliche Ausdehnung, und die kann und wird gemappt werden. Das Eintragen dieser Objekte als Punkt ist dann eine - vollkommen zulässige - Abstraktion. Wenn jemand aber anfinge, gezielt flächige Objekte in Punkte zu überführen, wäre ich davon wenig angetan, weil dabei Informationen verloren gingen, man also Arbeit früherer Mapper zerstört.
Im Übrigen fallen mir auch Konstrukte oder Mapping-Praktiken ein, die trotz ihrer Verbreitung für mich ganz offensichtlich und 100 % eindeutig unsinnig, inkonsistent o.ä. sind. Ergibt sich dann aber in einer Diskussion, dass andere genau gegenteiliger Meinung sind, legt das den Schluss nahe, dass es eben doch weniger eindeutig ist als angenommen.
So mache ich das auch. Aber folgendes reales Szenario finde ich dann doch etwas komisch.
In einem Supermarkt gibt es einen Bäcker → zwei POIs → 2 Nodes
Der Bäcker macht zu → ein POI → POI-Infos auf Gebäude setzen
Ein neuer Bäcker eröffnet nach einigen Monaten wieder → zwei POIs → Infos wieder vom Gebäude weg, zwei Nodes
Oder man pappt den Supermarkt an die Fläche und den kleinen Bäcker mappt man als Node.
Was ist überhaupt ein POI? Ist ein Krankenhaus EIN POI, was ist ein Freizeitpark oder eine Hotelanlage? Sind das alles nur Punkte? Wie soll man denn die Ausdehnung der Hotelanlage darstellen? Manche dieser Sachen fassen ja viele sogar zu einer site-Relation zusammen.
Klar ist es von der Auswertung einfacher sich nur auf Nodes zu beschränken, aber ich denke wir brauchen einfach nur gute Tools. Und *osmconvert *ist das schon sehr gut.
Christian
Realistisch betrachtet kann man POIs nur als Relationen sauber mappen. Es sind nun mal keine physischen Objekte, sondern nur abstrakte Eigenschaften, die einen Bezug zu Geodaten haben. Das wäre ein sauberes und konsistentes Datenmodell und löst alle oben angesprochenen Probleme (außer der einfachen Auswertung). Das Krankenhaus wäre dann eine POI-Relation mit mehreren Gebäuden usw., der Supermarkt mit Bäcker wären zwei POI-Relationen, die potentiell das gleiche Gebäude als Geometrie beinhalten. Und der Supermarkt ohne Bäcker ist eben nur eine POI-Relation, die das Gebäude enthält.
Leider aber ist das relativ komplex, die Unterstützung unserer Editoren für Relationen nur begrenzt gut und die Auswertung von sowas schwer. Daher gibt es verschiedene Abstraktionen davon, die alle ihre Daseinsberechtigung haben. Eine davon ist, die Eigenschaften des POIs an den Weg selbst zu packen. Das ist sehr ähnlich dazu, einen geschlossenen Weg als Fläche zu verwenden, obwohl man dafür eigentlich besser in jedem Fall eine echte Fläche (in unserem aktuellen Schema also ein Multipolygon) hernehmen würde. Diese Abstraktion ist besonders gut geeignet, denn solange die Geometrie mit einem Weg dargestellt werden kann, geht so nicht die geringste Information verloren. Die Unterstützung dafür, sowohl von Editoren als auch Auswertern, ist außerdem ziemlich gut. Das Krankenhaus (mit den mehreren Gebäuden) ist so natürlich nicht richtig darstellbar - der Supermarkt allein aber sehr gut. Außerdem entspricht diese Darstellung der menschlichen Wahrnehmung - das Gebäude, das von ALDI gebaut wurde und dessen Fläche zu 90% von ALDI benutzt wird und an dem vorne groß ALDI drauf steht IST der ALDI - zumindest für geschätzte 99,9% der Menschen 
Die andere gängige Abstraktion ist der Punkt mit allen Informationen. Diese Variante hat natürlich auch ihre Vorteile - sie ist noch etwas leichter einzutragen und auszuwerten (allerdings ist die Unterstützung für erstere Variante wirklich nicht schlecht, so dass der Unterschied nicht sehr groß ist), aber auch ihre Nachteile. Die Verknüpfung zur Geometrie fällt vollständig weg, der menschlichen Wahrnehmung entspricht diese Darstellung eher weniger. Wenn ich aber nicht die bessere Variante mit den Relationen verwenden will, ist das die Abstraktion, die es ermöglicht, mehrere POIs zumindest innerhalb (wenn auch ohne logische Verbindung zu) einer Geometrie unterzubringen. Sie kann dann auch manchmal besser der Wahrnehmung entsprechen: Wenn sich mehrere Geschäfte ein Gebäude teilen, wird das Gebäude eher nicht stellvertretend für eines der Geschäfte wahrgenommen. Es hat dann ja auch nicht nur die Gestaltung eines Geschäftes und wurde meist nicht von einem der Unternehmen allein erbaut. Für den Fall des Supermarkts mit Bäcker würde ich allerdings zu einer Kombination der beiden Abstraktionen greifen, da das Gebäude meist als zum Supermarkt gehörig wahrgenommen wird (und meistens von diesem ja auch erbaut und unterhalten wird), weshalb die Auszeichnung der Fläche damit gerechtfertigt ist. Der Bäcker kommt dann einfach als untergeordneter Punkt dazu.
(Und falls das nicht klargeworden sein sollte: Ich widerspreche dem Threadersteller und lehne Punkte für POIs mit Ausdehnung ab, wenn nicht unbedingt nötig)
Ich hatte am Anfang in meinem Ort - weil ich wusste, wo der Eingang ist - die Häuser als building=* mit node entrance=* (jetzt *=main) und der kompletten Adresse eingezeichnet. Da (damals) die Adresse zum Gebäude gehörte, sollte sie auch an diese . (Umtaggen war mir aber damals zu aufwendig).
Das Gebäude hat einen (Haupt-)Eingang: danach geht es gerade zur “Hotelrezeption” - rechts durch eine Tür in die Gaststätte und durch eine gegenüberliegnde Tür zum Friseur. Alle haben die gleiche Adresse, aber unterschiedliche website, phone, name. Also auch so als POI eingetragen. Das Hotel erstreckt sich über zwei Etagen - in der ersten wohnt noch Herr Mustermann - der Hotelbetreiber und Eigentümer. Deshalb hatte ich das Gebäude zum Hotel “erklärt”.
Nun, es lässt sich ändern → Hotel vom Gebäude als zusätzlichen POI ins Gebäude. Und ist das dann einfach building=yes oder building Aber kommt dann nicht wieder jemand, der sagt: Die Hauptnutzung sollte an das Gebäude. (Wohnhäuser in Innenstädten mit Geschäften im Erdgeschoß und Büros in den unteren Etagen sind doch Wohngebäude - oder nur Gebäude?)
Frag mal einer die Mapper, die den Murks der Wheelmapper regelmäßig aufgeräumt haben, weil letztere einen unfertigen Editor auf ein Massenpublikum losgelassen haben. Damit wären wir wieder bei den unausgereiften Anwendungen - ich bedaure, falls meine Äußerung bei Dir nun zu erneuter Emesis führt.
Die Grundfrage des Problems ist eigentlich eine andere: Sind die Eigenschaften des “POIs” am richtigen Element angehängt.
Die meisten “POIs”, die als Polygon gemappt sind, sind doch nur Tags an buildings. Und das ist meistens falsch. Warum? Weil das Gebäude eben nicht so wie der POI heißt oder wie bei Aldi meistens gar keinen Namen hat. Wenn man den Aldi schon als Polygon mappen will, dann schon gleich als Ring um Gebäude UND Parkplatz. Dann erübrigen sich auch häufige Fantasiename wie “Aldi-Parkplatz”, “Besucherparkplatz” und dergleichen.
Seit einiger Zeit sehe ich, dass dieses letztgenannte Taggingprinzip zumindest bei Schulen schon Schule macht Das Schulgelände bekommt den Schulnamen und die Einzelgebäude können “richtige” Namen -so vorhanden- oder auch lokale Namen (wie “Südflügel”) bekommen.
Leider gibt es genügend Mapper, die nach dem Prinzip “eine Fläche ist besser als ein Punkt” die Arbeit von Vor-Ort-Erfassern einfach abändern (der POI wird einfach an das darunterliegende Gebäude gehängt - auch wenn sich noch weitere (nicht gemappte) POIs und Wohnungen darin befinden). Das eigentlich sehr schöne buildings_tools-Plugin ist sogar standardmäßig so eingestellt, einen innerhalb des neuen Gebäudes liegenden POI zu verwursten (glücklicherweise habe ich die Einstellungsmöglichkeit gefunden - und sofort ausgeschaltet) 
Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.
Wenn sich nur ein POI am Gebäude befindet, auch wenn es nur ein kleines ist, es gleich an das gesamte Gebäudepolygon zu hängen, ist auch ein wenig übertrieben. Wenn die Fläche bekannt ist, würde ich ein eigenes Polygon anstreben (mit Stockwerksangabe).
LG Jimmy
PS: Bitte nicht daran aufhängen, dass im POI “Point” steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.