+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
Errt,
zwei nur? Zähl mal nach.
LG,
-moenk
Mondschein,
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.
LG,
-moenk
Christian,
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.
LG,
-moenk
Moin,
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!
LG,
-moenk
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…
Thomas,
schön dass es das was gibt - darum hab ich die Lösung immer noch nicht hier auf dem Tisch. Komm, mach schon, ist doch nur eine Zeile
LG,
-moenk
Du erinnerst mich gerade stark an jemanden, der auch hier im Forum aktiv ist…
Aber ich bediene auch für dich gerne google: http://wiki.openstreetmap.org/wiki/Osmconvert#Dispose_of_Ways_and_Relations_and_Convert_them_to_Nodes
Thomas,
mir würde reichen wenn der Blitzer überhaupt erst mal eingetragen ist - das Thema fasst aber kaum noch einer an, weil per verkopfter Definition so verkompliziert dass es schon abschreckend ist, seinen Beitrag dazu zu leisten. Verstehst Du nicht dass es Leute gibt, die nicht so schlau sind wie wir und die nur einen Blitzer eintragen würden wenn es einfach ist?
LG,
-moenk
JOSM > Punkt setzen > Vorlage > Straße > Wegpunkt > Radar
(weil ich grad JOSM nur in englisch da hab: JOSM > add point > Presets > highways > Waypoints > Speed camera)
Fertig.
Was ist mit YAPIS (Blitzer eintragen) oder über OSB (hier ist ein “Schwarzblitzer”)?
Richtig ist - die Leute müssen es wissen → also Werbung (in der Gemeinde → die wimmelt ab. Habe mit Mühe eine OSB_Karte auf der Gemeindeseite verlinken können.).
Geri,
YAPIS kenn ich, find ich auch gut, arbeitet auch nur mit Punkten. Was meiste was ich mir zu dem Thema alles anhören muss und wie oft einer um die Ecke kommt, der mich auf diesen “Bug” hinweisen will.
Dieses “POI als Polygon”-Problem ist nur ein sichtbares Symptom der OSM-Community, die alles möglichst universell und perfekt machen will, dabei aber leicht an den Bedürfnissen der Zielgruppe vorbeischießt.
LG,
-moenk