Sinnvolle Node-Dichte auf einem Weg oder Overkill?

highflyer74 · 2024-03-25T13:01:30.313Z

Hallo und willkommen im OSM-Forum!

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.

Zum Thema wie viele Nodes man verwenden sollte: Good practice - OpenStreetMap Wiki

Für Kurven ein gesundes Augenmaß, für Geraden ganze zwei Nodes.

Galbinus · 2024-03-25T13:39:32.665Z

Was für ein Aufschlag. Sich so hier einzuführen und eine solche Haltung zu signalisieren ist keine gute Basis für ein Gemeinschaftsprojekt wie OSM.

Es wäre schön, wenn Du Deine Haltung überdächtest.

Manuel_H · 2024-03-25T19:34:18.331Z

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.

user_msh:

Vielleicht sollte man Kurven prinzipiell abschaffen und nur noch gerade Linien zulassen.

Man kann noch so viele Nodes setzen, am Ende sind es doch nur Linien, denn OSM kennt keine Kurven.

user_msh:

in einer hinreichenden Qualität, die auch administrativen Ansprüchen genügen könnten. Mit der genaueren Digitalisierung, also einer erhöhten Node-Dichte erreicht man zum Beispiel auch, die deutlich genauere Generierung von Tracks in anderen Plattformen, welche OSM-Daten verwenden etc.

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.

user_msh:

Wenn Änderungen später notwendig werden, dann ist es eben so. Ich werde bis dahin aber nicht mit viereckigen Rädern herumfahren wollen müssen lassen werden…

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?

dieterdreist · 2024-03-25T22:19:54.026Z

Manuel_H:

Wenn jemand runde Kurven will, kann er die sich auch selber errechnen.

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)

Manuel_H · 2024-03-26T06:42:50.123Z

dieterdreist:

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.

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.

chris66 · 2024-03-26T07:06:09.800Z

Manuel_H:

Du redest viel von Genauigkeit, aber eine hohe Nodedichte ist nicht nicht das gleiche wie eine hohe Genauigkeit.

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.

OSM_RogerWilco · 2024-03-26T07:23:17.210Z

chris66:

Zu beachten wäre noch,

Ich finde nicht, dass man das beachten sollte.

FraukeLeo · 2024-03-26T07:31:21.513Z

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.

FraukeLeo · 2024-03-26T07:37:35.657Z

Manuel_H:

sowas kann jemand mit den Daten machen, die man sich runterlädt.

Du hast den Punkt von dieterdreist

dieterdreist:

weil man nicht weiß, ob es überhaupt eine Kurve ist, oder ein eckiger Polygonzug

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.

dieterdreist · 2024-03-26T07:55:31.000Z

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 · 2024-03-26T08:48:22.930Z

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.

seichter · 2024-03-26T09:04:46.444Z

One feature, Six mappers and still More ways to map it:

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.

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.

chris66 · 2024-03-26T09:47:08.169Z

FraukeLeo:

Ich finde auch nicht, dass man das beachten sollte. Das wäre Mappen für den Garmin.

Na ja, auch der kommende OSM Standard (Vektor) Style könnte betroffen sein.

Minutely updated vector tiles demo - #9 by milet

dieterdreist · 2024-03-26T14:19:24.000Z

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.

Mammi71 · 2024-03-26T15:00:23.228Z

dieterdreist:

z.B. kann man ein Gebäude rechtwinklig zeichnen

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.

Manuel_H · 2024-03-26T16:30:08.961Z

FraukeLeo:

anscheinend nicht verstanden.

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.

FraukeLeo · 2024-03-26T17:09:08.338Z

One feature, Six mappers and still More ways to map it:

dieterdreist:

z.B. kann man ein Gebäude rechtwinklig zeichnen

Es geht um Kurven und gerade eben nicht um rechte Winkel!

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?

chris66 · 2024-04-22T07:41:49.958Z

chris66:

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.

Hier ein schönes Beispiel. Ein Brunnen (12m Durchmesser) gemappt mit 350 Nodes.
Und wird dann auf der “Standardkarte” noch nicht mal gerendert.

grafik1012×671 38.9 KB

dieterdreist · 2024-04-22T10:21:04.000Z

sieht für mich so aus als wären alleine in diesem kleinen Ausschnitt schon 3-4 nodes optimierbar.

AB-inf-x-chg-AB · 2024-04-22T17:02:03.254Z

chris66:

Und wird dann auf der “Standardkarte” noch nicht mal gerendert.

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:

image239×504 45.2 KB