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.
Oli-wan,
ich bin da recht unemotional. Ändert aber nichts dran, dass ich POI als Polygon für falsch halte und das Problem mit den Wheelmapper mit POI-Punkten hätte auch vermieden werden können. Für mich heißt es auch sich der Realität der Anwendungen zu stellen, wenn man sich Gedanken über ein Datenmodell macht. Das ist ein Problem von OSM: Das Datenmodell ist historisch gewachsen und erfüllt nicht was man an allgemeinen Qualitätsmaßstäben an Geodaten anlegt - daran gemessen ist völliger Murks. Das kann man nun verteidigen oder schrittweise beheben.
LG,
-moenk
Erwin,
danke für Deinen Hinweis. Das erschien mir schon so trivial, dass ich vergessen habe darauf hinzuweisen. Allein das ist schon Grund genug POI nur als Punkt zu mappen.
LG,
-moenk
+1
point kann auch einfach “Ort” heißen ( http://www.dict.cc/?s=point ) und interest kann mit “Wichtigkeit” oder “Bedeutung” übersett werden ( http://www.dict.cc/?s=interest&failed_kw=interest ), woraus sich für “point of interest” “Ort von Bedeutung” ergibt.
S-Man,
danke auch für Deinen Hinweis, über den ich erst mal nachdenken musste. Es ändert sich aber nichts für mich. Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von “is_in” als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.
LG,
-moenk
Jimmy.
so ist das nicht. Das Gebäude des Supermarkts ist doch da mit seiner Fläche. Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte. Und der Bäcker-Laden vorweg kann auch indoor kartiert werden, dazu ein POI auf den Eingang.
LG,
-moenk
Dann ist jeder “POI” also auch als “building:entrance” zu taggen… (oder sollten wir dann nicht gleich auch noch shop/amenity/…:entrance einführen?)
Thomas,
das hängt dann davon ab, wie der POI liegt - wenn er denn auf dem Eingang liegt, eine gute Idee. Ich würd das nicht mal vorschreiben wollen, vielleicht gibts auch Fälle wo man den POI nicht auf den Eingang legen will. Vielleicht gibt sogar Fälle, wo man den POI auf einen Zuweg mit einem Schild legen will, weil man sonst gar nicht hinfindet.
LG,
-moenk
Dann wiedersprichst du dir jetzt gerade selber: Geradeeben sagst du der POI darf nicht irgendwo liegen sondern genau am eingang und jetzt liegt er aufeinmal am “Zuweg” - oder sollen wir POIs setzen? Ähnlich einer Krümelspur? Dann bräuchten wir auch keine routing-Software mehr - einfach der POIs-Kette folgen…
Also für mich ist und bleibt ein POI ein “Ort” und kein “Punkt” - ein Schloss/Burg kann ja zB ein “POI” sein - da will ich dann aber nicht nur einen Punkt im Innenhof sehen, sondern das Bauwerk in seiner Gesamtheit - somit bleibe ich bei Tagging-Schema alt: “Ein POI” > way/polygon - “mehrere POIs” > nodes
Hallo,
POI? was ist ein POI?
Aber was ist es genau? Es ist immer das, was der jeweilige Betrachter darin sieht. Für den einen sind es geschichtliche Orte, den anderen ehemalige Bahnstrecken, wieder andere Einkaufsläden, oder Taxistände. Dasraus ergibt sich für mich, daß ein POI sowohl Fläche, Linie oder Punkt sein kann (auch in Relationen). Diese POI’s immer als Punkte zu sehen, halte für unlogisch.
POI ist wie ein Gummituch. Jeder zieht es dahin, wo er es haben will.
Sven
Die is_in-Relation macht die Sachen aber für alle Seiten komplexer und ohne die geht die Beziehung zwischen Fläche und POI verloren. Den automatisch darin zu verorten ist noch wesentlich blöder für die Auswerter. Und es gibt ja durchaus verschiedene Auswerter. Für Rederer ist es Mist, wenn der POI auf dem Gebäuderand liegt wie ein Eingang, denn dann landet der Schriftzug völlig falsch oder man muss deutlich mehr Aufwand betreiben. Letzlich bleiben insgesamt fast nur Nachteile.
Errt,
ich will die Relation oder “is_in”-Geschichte auch nicht haben. Mir reicht wenn der Punkt in der Fläche liegt. Und die Attribute für den POI an dem Punkt und nicht am Gebäude hängen. Wo der Renderer den Schriftzug hinsetzt ist mir eigentlich recht egal, mir ist wichtiger, dass man alle POI bekommt wenn man die z.B. über die Overpass-API abfragt.
LG,
-moenk
Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.