Diskussionen sind bei OSM normal und gewollt und spielen eine große Rolle dabei, wie wir gemeinsam die Datenqualität über lange Zeit hoch halten. Da kommt es auch vor, dass das eigene Tun kritisiert oder hinterfragt wird. Das sollte man dann auch aushalten. Solange alles in einem freundlichen Ton verläuft, ist alles gut. Änderungssätze und dieses Forum sind der Ort, um Diskussionen zu führen.
Die unverständliche Trotzreaktion und das wilde Austeilen in alle Richtungen bringen hier niemanden was.
Und dann ist OSM ein Gemeinschaftsprojekt. Sowohl das Mapping als auch die Diskussion hier, bei der jeder seine Meinung äußert.
Man kann noch so viele Nodes setzen, am Ende sind es doch nur Linien, denn OSM kennt keine Kurven.
Du postulierst hier so einiges zur Verteidigung, was für mich ziemlich aus der Luft gegriffen zu sein scheint.
Wer definiert “hinreichende Qualität”? Was sind die administrativen Ansprüche?
Du redest viel von Genauigkeit, aber eine hohe Nodedichte ist nicht nicht das gleiche wie eine hohe Genauigkeit. Vielmehr täuscht es optisch nur eine höhere Genauigkeit vor, die nicht existiert. Z.B. lag der Weg aus dem Beispiel mehrere Meter neben dem wahren Verlauf, während die Nodes so dicht aneinander waren, dass man denken könnte, dass der Weg auf unter einen Meter genau bestimmt wurde, was aber nicht der Fall war.
Ein quasi kosmetisches Abrunden von ways bringt auch externen Nutzern nichts. es erhöht erstmal nur den Aufwand beim Verarbeiten. Wenn jemand runde Kurven will, kann er die sich auch selber errechnen.
Am Ende benutzen schon unzählige Dienste OSM als Quelle und ich kann mich nicht vorstellen, dass dieser vermeintliche Qualitätsmangel existiert.
Es geht um das gesunde Mittelmaße. Deine glattpolierten Ovale sind eben nicht besser als ein rauhes Rad. Sie erschweren nur die Weiterverarbeitung zum finalen runden Rad.
PS: Und ich frage mich, wie du mit der Einstellung sinnvoll auf OSM mappen willst. Darf ich deine Aussagen so verstehen, dass du nicht mal völlig neutrale Anfragen antworten willst, wie der zu dem Weg bei der Hohen Linde?
das geht nicht, weil man nicht weiß, ob es überhaupt eine Kurve ist, oder ein eckiger Polygonzug. Man kann zuviele/überflüssige Nodes einfach algorithmisch entfernen, aber man kann sie nicht hinzufügen ohne zu raten.
(habe nur diesen Satz rausgegriffen, dem Rest stimme ich aber zu)
Natürlich erzeugt das keine Daten, sondern glättet nur optisch. Für Wege und Straßen kann man das machen, weil sich die vorhandenen Punkte meist schon ausreichend der Wahrheit annähern. Mit einem Schwellwert für große Winkel bleiben so auch Knicke drin.
Aber, wie gesagt, sowas kann jemand mit den Daten machen, die man sich runterlädt. Es ist nichts, was man als Daten in die DB füttern sollte.
Und wenn man es per Auge macht, ist es auch nicht besser.
Zu beachten wäre noch, dass manche Anwendungen (zB Garmin, Vectortiles) Koordinaten runden und dann sorgt eine höhere Punktdichte zu einer schlechteren (zackigeren) Darstellung.
Ich finde auch nicht, dass man das beachten sollte. Das wäre Mappen für den Garmin.
Ein Kreisverkehr ist (von Ausnahmen abgesehen) kreisförmig und nicht achteckig. 200 Nodes für einen Vollkreis fände ich auch übertrieben, aber 12 (das sind 30° Richtungsänderung an jedem Node!) sind mir zu wenig. Wenn Garmin mit mehr Nodes nicht klarkommt, dann muss Garmin seine Rundungsalgorithmen überarbeiten oder in seinem Datenbankexport die Punktdichte reduzieren, dagegen hat niemand was. Aber Garmins Anforderungen können nicht die verfügbare Punktedichte für sämtliche Anwender der OSM-Datenbank begrenzen.
anscheinend nicht verstanden. Nein, so was kann man nicht nachträglich mit runtergeladenen Daten machen, weil man nämlich keine Information darüber hat, ob der eckige Polygonzug a) eine unpräzise gemappte Kurve ist oder b) vielleicht tatsächlich auch real so eckig verläuft, also bereits präzise ist. Bei Straßenkurven gibts das selten, bei Fußwegen dagegen sehr oft. Im Fall b) hätte man mit automatischem Ausrunden falsche Daten.
Aber, wie gesagt, sowas kann jemand mit den Daten machen, die man sich runterlädt.
ich habe damit schonmal experimentiert (mapnik), und es dann sein gelassen weil es manchmal die Sache verschlechtert hat. Es dürfen eben nicht alle Straßen oder Wasserflächen, etc. abgerundet werden, und die vorhandenen sind auch meistens rund genug so dass es sowieso nicht viel bringt
Mammi71
(One feature, Six mappers and still More ways to map it)
51
Wir sollten uns hier nicht an den Diskussionen in den Extremen aufhalten. Das Argument, alle 20-50 cm einen Stützpunkt zu setzen, weil manche Kreisverkehre aus Achtecken bestehen, zieht bei mir nicht. Ich denke, dass wir uns hier alle einig sind, dass nur 8 Stützpunkte für einen Kreisverkehr oder nur 3 Stützpunkte für eine Spitzkehre zu wenig sind. In diesen Fällen runde ich mit zusätzlichen Stützpunkten ebenfalls den Wegeverlauf aus. Das ist aber kein Grund ins gegenteilige Extrem zu verfallen.
Eine Punktdichte von deutlich unter einem Meter gaukelt eine Genauigkeit vor, die wir weder bei der Erfassung mit GPS-Tracks noch beim Abzeichnen von Luftbildern haben (von den wenigen Gegenden mit erstklassigen hochgenauen orhogonalen Luftbildern vielleicht abgesehen).
Ich habe mir mal einige Spitzkehren, die ich mal verfeinert und abgerundet hatte, noch einmal angesehen. Ich bin dabei zumeist mit 7-10 Stützpunkten ausgekommen. Der Punktabstand beträgt dabei ca. 6 - 7,5 m. Der Linienverlauf ist dabei etwas gemittelt, d.h. die Stützpunkte liegen knapp neben der Mittellinie (Markierung auf der Straße) Richtung Außenseite, der OSM-Way schneidet aber zwischen zwei Punkten die Mittellinie. Die reale Abweichung zwischen Mittellinie und OSM-Way beträgt an den Stellen, wo ich gemessen habe, zwischen 20 und 45 cm bei einer Straßenbreite von 10-12 m. Ich persönlich halte das bereits für hinreichend genau, der Fehler durch Lageversatz des Luftbildes oder der GPS-Spur ist wahrscheinlich größer.
Sollte jemand der Meinung sein, die Punktdichte zu verdoppeln, meinetwegen zu verdreifachen, wäre das weiterhin absolut i.O. Bei einem Punktabstand von 3 m ist bei einem Kurvenradius von ca. 12 m (gemessen an der Mittellinie) der Abstand des OSM-Way zur Mittellinie bereits kaum größer als die Mittellinie breit ist.
Ein Punktabstand von unter einem Meter bringt dann aber keinen effektiven Genauigkeitsgewinn mehr.
Bei Wirtschaftswegen und Pfaden sowie Bachverläufen handle ich nach Augenmaß, aber auch da eher nicht mit Abständen unter 1 m.
Bei einem Wanderweg darf der Abstand natürlich geringer sein.
Ich versuche generell die Punkte so zu setzen, dass die Verbindungslinie innerhalb der physischen Wegbreite liegt.
Mit dem spline-Plugin geht das übrigens auch, ohne dass man Gefahr läuft, eine Sehnenscheidenentzündung durch Tausende Mausklicks zu bekommen.
Eine Punktdichte von deutlich unter einem Meter gaukelt eine Genauigkeit vor, die wir weder bei der Erfassung mit GPS-Tracks noch beim Abzeichnen von Luftbildern haben (von den wenigen Gegenden mit erstklassigen hochgenauen orhogonalen Luftbildern vielleicht abgesehen).
allerdings muss man unterscheiden zwischen (absoluter) Lagegenauigkeit und relativer Genauigkeit der einzelnen Punkte zueinander, letzteres ist für die Form wichtig, z.B. kann man ein Gebäude rechtwinklig zeichnen obwohl es 2 m zu weit nördlich liegt (und es wird kaum auffallen), wenn man nur einen Punkt um 2m verschiebt wird es krumm aussehen.
1 Like
Mammi71
(One feature, Six mappers and still More ways to map it)
55
Es geht um Kurven und gerade eben nicht um rechte Winkel!
Und es geht auch nicht um die relative Abweichung der Punkte zueinander, die könnte theoretisch sogar absolut exakt sein, sondern es geht um die Abweichung der geraden Verbindung zwischen zwei Punkten zur tatsächlichen Kurve.
Doch, ich habe es sehr wohl verstanden.
Und ob das jemand mit runtergeladenen Daten macht oder nicht, ist, wie gesagt, jedem selbst überlassen. Es geht ausdrücklich nicht um das Interpolieren der Daten in der Datenbank. Aber da das hier nicht das eigentliche Thema ist, habe ich das nicht weiter ausgeführt.
Sorry, das kriegst du jetzt in den falschen Hals Das mit dem rechtwinkligen Gebäude war doch nur ein Beispiel dafür, dass die präzise Abbildung eines Objekts und seine präzise Lage im Koordinatensystem zwei unterschiedliche Dinge sind. Wenn ein Objekt, sei es eine Kurve oder ein Gebäude, in der Form genau gemappt ist, ist das auch dann ein Gewinn für unsere Daten, wenn die absolute Lage dieser Form ein paar Meter danebenliegt.
Und da gebe ich ihm recht. Deshalb ist “so genau sind unsere Luftbilder ja gar nicht” kein Argument. Sie mögen in der Lage ein paar Meter danebenliegen und können dennoch die Geometrie der Kurve sehr genau wiedergeben. Warum soll diese Geometrie dann nicht in der vorliegenden Genauigkeit in die Datenbank?
Liegt wohl an der derzeitigen Renderregel (des carto-Standard-Layers) für highway=pedestrian-Flächen, oder es müsste per MP-Relation definiert werden, also mit ausgeschnittenen natural=water Bereich…
Edit:
Bei mehr als die Hälfte der anderen auf osm.org eingebundenen Map Layer wird es angezeigt, siehe:
Das mit dem rechtwinkligen Gebäude war doch nur ein Beispiel dafür, dass die präzise Abbildung eines Objekts und seine präzise Lage im Koordinatensystem zwei unterschiedliche Dinge sind. Wenn ein Objekt, sei es eine Kurve oder ein Gebäude, in der Form genau gemappt ist, ist das auch dann ein Gewinn für unsere Daten, wenn die absolute Lage dieser Form ein paar Meter danebenliegt.
