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
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.
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.
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.
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.
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?
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.
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.
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.
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.
das Beispiel ist deswegen gut, weil es zeigt was für ein Rad die für das eine, und erst recht für das andere drehen mussten. Und nur weil POI in Ways und Relationen festgehalten wird.
danke auch für Deine Unterstützung. OSM würde an vielen Stellen geholfen, wenn man nicht den genialsten, sondern den einfachsten Weg wählen würde. Sonst fehlt Akzeptanz! Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen. Noch mehr Beispiele auf Nachfrage.
wo das ja alles ganz einfach ist: Ich habe hier einen einfachen Weg, um POI aus der OSM fürs Garmin aufzubereiten. Allerdings nur für Punkte. Vielleicht krieg ich noch einen sachdienlichen Hinweis, was ich ergänzen muss um auch Polygone (oder Ways, jaja) mit drin zu haben. http://www.moenk.de/archives/75-Punkte-der-OpenStreetMap-in-Garmin-POI-konvertieren.html
Ist sicher nur eine Zeile, aber ich kann ja kein RTFM und möchte nicht noch ein Kilo Software zu den Standardstools dazuinstallieren die ich eh schon habe. Denn legt mal los!
Weil genau dieses Beispiel zeigt, dass zum Beispiel nicht nur schwarz/weiß vorhanden ist. es gibt Blitzer die blitzen von vorne - da willst du nicht gewarnt sein, wenn du auf Höhe des Blitzers bist. Es gibt Blitzer die blitzen von hinten - da reicht es wenn du gewarnt wirst, wenn du auf deren Höhe bist. Und dann gibt es Blitzer die können gedreht werden.
Und dann gibt es Blitzer die blitzen bei Rotlicht… usw.
Und deine way-to-nodes - da gibt es was von osmconvert…
