Als ich mit OSM angefangen hatte, fand ich es befremdlich, dass man Kurven mit ganz vielen kleinen gerade Segmenten malen soll (je nach Mapper gibts da andere Ansichten wie “fein” das sein muss) statt Splines zu nutzen. Irgendwann wird man dann ja betriebsblind und man nimmt es so hin. Weil ich gerade wieder mehr mit Vektorgrafik-Programmen arbeite, ist es mir wieder eingefallen.
Also, wieso sind Splines eigentlich keine Grund-Datenstrukturen? Wie ist es in der Geodäsie außerhalb von OpenStreetMap?
es gibt auch Splines als Geodaten, aber es würde dadurch sicherlich deutlich komplizierter zu mappen. Wenn es sie gäbe wäre das Nichtverwenden keine Option mehr, über kurz oder lang wären sie überall verbreitet und wenn man was ändern will muss man dann Splines anfassen.
Ich glaube, Osmarender hat Splines (oder irgendwas anderes interpolierendes) für die Darstellung von Wegen verwendet, glücklicherweise nicht für Häuser. Sah oft gut aus, manchmal weniger gut, weil Straßen sich ungewollt schlängelten. Letzteres lag natürlich daran, dass die Mehrheit der Renderer und alle Editoren Striche gemalt haben und nur ein Renderer Kurven und dass man sich die Darstellung beim Mappen nicht aussuchen kann.
Geht auch ohne. Mein Lieblings-Mal-Programm “xfig” macht das z. B.
Es werden dann aber wohl paar mehr Punkte nötig als wenn man die Krümmung noch explizit angibt.
bei den Splines gibt es unterschiedliche Arten, welche wo die Punkte auf der Linie liegen und solche wo das nicht der Fall ist. Auch kann man einzelne Punkte stärker gewichten, Tangentenvektoren und Stärke/Länge, etc.
Normalerweise will man so wenige Kontrollpunkte wie nötig um die Kurve darstellen zu können.
Man kann auch mit Mapnik Kurven rendern, aber das macht nur dann Sinn wenn es auch Kurven sind die abgebildet werden sollen, und wir taggen das normalerweise nicht dazu, und gehen allgemein eher davon aus, dass es keine sind.
Gut, bei OSM wäre wohl die Devise dass User so wenig wie möglich falsch machen können, also vermutlich so die “xfig”-Variante. Wenn ich die Wiki-Artikel richtig verstanden habe, wären das dann “Splines”, sowas wie in dem Screenshot oben zu sehen (mit Kontrollpunkten) wären Bézierkurven, ja?
In der Anfangszeit war die Technik darauf ausgelegt, GPS Tracks zu importieren. Auch heute noch siehst Du das den Wegen an: Teilweise 500 oder mehr Knoten pro Kilometer auf einem einfachen Waldweg.
Mit dem aufkommen anderer Quellen hat sich ein deutlich einfacheres System etabliert, so dass Kurven oft nur aus 3-4 Punkten bestehen. Dass lässt sich wesentlich einfacher abzeichnen und warten.
Und erst wenn die Auflösung entsprechend grob ist, macht es ja Sinn, auch andere Verbindungen zwischen Punkten als geraden anzunehmen.
Gestalterisch würde dass ja viel bringen - natürliche Flüsse und Bäche, Seeufer etc sind ja so gut wie nie “gerade”
Bei Splines kannst Du davon ausgehen, dass Du Stunden mit dem Zurechtzupfen der Tangentenwinkel und -Längen verbringen kannst, jeder neu eingefügte Punkt (oder gelöschte) wird erneute Anpassungen erfordern, etc. M.E. ist das jetzige System wesentlich einfacher und schneller zu verändern als es echte Kurven wären, und in der Regel gäbe es kaum echte Verbesserungen.
Was man m.E. einführen könnte wäre ein tag (oder metadatum), welches explizit sagt, wie die Übergänge sind (ob es sich bei einem way um eine Annäherung an eine Kurve handelt oder ob es Stufen/Ecken sein sollen). Das gilt auch für Übergänge von anderen Attributen, z.B. width bei Straßen: ist das eine “weiche” Annäherung (und wenn ja, immer gleich, oder “gekurvt”, abnehmend, zunehmend, etc.), oder gibt es hart gestufte Übergänge.
… im Straßenbau und im heutigen Bahnbau, während die Bahner früher lieber mit der kubischen Parabel gerechnet haben …
xfig ist en schönes Programm, dass ich auch ab und zu noch verwendet, aber die Splines sind andere als in allen anderen Programmen, was dann bei Konvertierungen etc. Probleme bereiten kann.
Kurzum: Es gibt massig Kurvenarten, man müsste sicherst mal auf eine einigen und die dann allen Programmen beibringen, denn es ist wenig sinnvoll, wenn man zwar “spline: ja” anklicken kann, aber nicht sieht, was man damit anrichtet …
… und es gab hier im Forum auch schon Diskussionen über “komische Render-Ergebnisse”, wo dann eigentlich unrundes in einigen Karten plötzlich reichlich geschwungen war …
Die xfig-Splines brauchen in der Tat keine weiteren Parameter an den Knoten, wären von daher evtl. geeignet für OSM, aber das Ergebnis wird dadurch manchmal ziemlich eigenartig … Genau das Problem hätte OSM dann auch.
“Steuerbare” Splines bräuchten wiederum Ergänzungen am Datenmodell.
Und wann dürfte der Renderer selbst entscheiden, was rund und was gerade werden soll. Tags nachrüsten dafür würde eine unendliche Geschichte und bläht das Datenmodell auf. Zwichenpunkte spart es ja nicht wirklich, die bleiben ja als Leichen drin …
+1. Mir persönlich würde es sicher auch Spaß machen, Kurven über Splines abzubilden. Aber sie sind nicht „idiotensicher“ – beispielsweise könnte dann ein versehentlich eingebauter 360°-Vollkreis mit 0,001 m Radius unbemerkt in den Daten stehen bleiben, was mit dem derzeitigen n-Eck-Modell eher schwierig ist (wenn auch nicht komplett unmöglich, aber aus Versehen passiert so was eher nicht).
Viele Kollegen bemerken nicht mal, wenn sie beim Verschieben von Ways an den Übergängen Zickzackkurven einbauen – will man denen wirklich Splines in den Werkzeugkasten legen?
Einer der Gründe dürfte auch heute noch sein, dass Stanndard SQL GIS auch nur aus Geraden zusammengesetzte Linienzüge kennt. PostGIS kann da zwar mittlerweiler mehr, aber die Unterstützung dafür müsste sich ja auch durch alle Tools hindurch ziehen …
Die OpenCycleMap scheint das automatische Glätten bei Straßen inzwischen auch aufgegeben zu haben, da wurden letztes Jahr noch Negativbeispiele verlinkt, die jetzt normal eckig aussehen.
