Sinnvolle Node-Dichte auf einem Weg oder Overkill?

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

Manuel_H · 2024-04-22T17:42:41.463Z

Wenn man iD “Kreisförmig machen” auswählt, wird das krakelige Ding erst richtig rund.

Mammi71 · 2024-04-22T21:14:42.855Z

AB-inf-x-chg-AB:

oder es müsste per MP-Relation definiert werden, also mit ausgeschnittenen natural=water Bereich…

Ja, das pedestrian wird im carto-Stil einfach über alles drübergebügelt.

chris66 · 2024-04-23T14:08:54.713Z

AB-inf-x-chg-AB:

also mit ausgeschnittenen natural=water Bereich…

Es war bereits als MP definiert, allerdings waren die Tags getripelt (am MP, am Inner und am Outer ). Habs mal ein bisschen bereinigt und das Rendering auf Carto ist nun erstklassig.