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.
+1
Errt,
hast dazu mal ein Beispiel? Punkte lassen sich einfach abfragem Zentroide wäre mir neu.
LG,
-moenk
Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt’s auf ein paar Pixel lechts oder rinks nicht an.
Du hast: “Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!” vergessen.
Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?
Gruss Christian
Das Zitat lese sich als ‘technisch kein Problem, leider noch nicht umgesetzt’ 
Natürlich tut das ein guter Renderer. Aber das kann er nur solange er den Zusammenhang kennt. Und wenn ich nunmal irgendwohin (weiter oben hieß es schon, auf den Parkplatz) einen Punkt setze, kann er den nicht mit der Fläche in Verbindung bringen. Man sollte es ihm doch nicht unnötig schwer machen, wenn doch eine der Hauptbegründungen für die Punktvariante war, dass sei für die Auswerter leichter - ist es eben nicht für alle, nur für bestimmte.
Ich habe nichts gegen eine Verbesserung. Aber hier sehe ich eben einen Rückschritt. Und es ist ja nun so, dass das Ganze seit längerem so praktiziert wird und die meisten damit keine Probleme haben und die Tool-Unterstützung schon recht gut ist.
Was uns verloren geht, wenn wir das umsetzen? Der Bezug von Fläche und Nutzung geht uns verloren. Das kann man natürlich unproblematisch finden, mich würde es stören. Viele Renderer stellen beispielsweise Gebäude mit POI anders da, als solche ohne, das verbessert die Orientierung auf der Karte doch gewaltig. OSM wirbt doch gerade auch damit, dass wir semantisch wertvolle Daten mit Beziehungen der geographischen Objekte untereinander und mit weiterführenden Informationen haben, und nicht nur, wie kommerzielle Datensätze, Punktwolken mit gerade so viel Information, wie für wenige Hauptanwendungsfälle gerade so notwendig.
Natürlich müssen wir darauf achten, dass unsere Daten leicht zu erfassen und leicht zu verwerten sind. Aber mal ehrlich: Zumindest mit JOSM (andere Editoren nutze ich zu wenig, um das beurteilen zu können) ist es kein bisschen komplexer, das mit Flächen zu erfassen. Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken. Aber mit Unterstützung der einschlägigen Werkzeuge (osmconvert wurde schon angesprochen) und der Tatsache, dass das als häufig benötigte und technisch nicht so komplexe Funktion ist und deshalb sicher auch von anderen Werkzeugen unterstützt werden wird (wie schon gesagt, schlagt es doch für die Overpass-API mal vor - wenn sie’s nicht doch schon kann), sehe ich auch keine allzu großen Hürden für Auswerter. Da haben wir wirklich wesentlich komplexere Daten, wenn es z.B. um Relationen, Multipolygone, ÖPNV-Linien geht.
Ok, ich habe ein großen Aldi (um beim Beispiel zu bleiben). Dieser hat zwei Eingänge. Einer ist nicht rollstuhltauglich, der andere schon. (nicht realitätsnah, aber egal 
Aktuelles mapping:
Gebäude+Aldi polygon. Auf diesem sind zwei entrance=yes nodes, wheelchair=yes/no jeweils. Meine (fiktive?) wheelchair-Routingsoftware kann also mich zum Aldi führen und weiss, dass sie direkt den entrance node mit wheelchair=yes ansteuern muss. Einfach, weil sie sieht, dass der Such-Treffer ein polygon ist und der zwei entrances nodes hat.
Vorgeschlagenes Mapping:
Gebäudepolygon und in der Mitte ein Aldi-Node. Das Gebäude hat auch jeweils die Entrance Nodes.
Meine routing-software hat jetzt einen Berg arbeit vor sich, rauszufinden, ob der Such-Treffer-Node jetzt innerhalb eines Gebäudes liegt. Dazu muss sie zusätzlich raten, dass beide entrance-nodes hoffentlich auch wirklich in den Supermarkt führen.
Alternativ:
Gebäudepolygon mit Aldinode am Haupteingang. Damit weiss erst recht keiner, dass der 20 meter danebenliegende wheelchair entrance auch in den supermarkt führt…
Alternativ 2:
Gebäudepolygon mit Aldinode in der Mitte. Dazu zwei Eingänge auf dem Gebäude und zwei footways von den Eingängen zum Aldi-Node. wird dann aber erstens hässlich und zweitens aufwändiger zu mappen.
Da gefällt mir das aktuelle Datenmodell irgendwie besser.
… nur kurz wegen der vorgerueckten Stunde:
Die “meisten” Mapper lesen dieses Forum nicht. Und die “meisten” von den hier Mitlesenden/-schreibenden arbeiten nicht in Projekten mit, die irgendwas zur Verfuegung stellen, dass dann von ‘Nicht-Mappern’ verwendet wird.
Leute wie moenk kriegen durch Fragen von Benutzern (anders als die “meisten”) mit, wie unlogisch und kompliziert unser Tagging-Modell an manchen Stellen ist und wie viele Probleme in der Praxis dadurch entstehen.
Wenn wir die Erfahrungen der “Verwerter” unserer Daten nicht Ernst nehmen, anstelle sie mit “Problem der Anwendung - mir doch egal, ich kippe in die DB was ich diese Woche gerade glaube, was en vogue ist!” abzubuegeln, dann werden wir dem Gedanken der “Foerderung freier Geodaten” wohl nicht wirklich gerecht.
Gruss Christian
Das wird aber auch nicht besser, wenn wir in die DB kippen, was gerade bei den “Verwertern” en vogue ist, wie du so schön sagst. Alles was wir für die tun können, ist vernünftige Schnittstellen zu schaffen, welches Datenmodell denen auch immer zu Grunde liegt. Und grundsätzlich kommt man nun mal nicht drumherum, sich mit dem Datenmodell auseinanderzusetzen, wenn man die Daten vernünftig verwerten will, so viele sollten da also nicht von Außen kommen und dann erwarten, dass alles irgendwie gebrauchsfertig vorliegt. Jedenfalls kritisiere ich, dass ihr behauptet, die vorgeschlagene Variante wäre für “die Auswerter” besser - das stimmt eben nicht. Sie ist für manche Nischen etwas einfacher, korrekt, aber Wege das zu ermöglichen wurden aufgezeigt, aber für andere Nischen wesentlich komplizierter, das wurde ebenfalls schon angesprochen, siehe auch HolgerJeromin über dir, Lösungsansätze dafür wurden aber nicht genannt. Warum also einen Weg forcieren, der zwar manche Auswertungen vereinfacht, andere aber fast unmöglich macht, wenn der aktuell eingeschlagene, natürlich sicher auch nicht perfekte, Weg für praktisch alles, was mir bisher an Auswertungen unserer Daten bekannt geworden ist, zumindest keine besonders großen Hürden aufwirft. Insbesondere ist das Beispiel mit der Wheelmap ungeeignet, denn das Problem war von Anfang an bekannt und obwohl grundsätzlich Lösungen existierten wurde eine halbfertige Anwendung auf die Öffentlichkeit losgelassen.
errt und HolgerJeromin:
+1
Das Beispiel mit Wheelmap ist auch deshalb ungeeignet, weil Wheelmap nicht nur ein Auswerter ist, sondern auch einen POI-Editor über die Internetseite bietet.
Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.
Gruß,
Mondschein
Komisch, ich muß da gerade an ein anderes Programm denken, dass sich wohl mit den gleichen Problemen rumschlagen muß.
Lösungsansatz A: Programm erweitern
Lösungsansatz B: Rohdaten vereinfachen
Ein Schelm, wer da Böses denkt
Gruss
walter