Integration der Kurvendarstellung in OSM

Ein guter Freund von mir fragte, warum wir eigentlich keine Kurven in OSM verwenden. Ich musste ihna auf die Grundstruktur von OSM verweisen worauf er antwortete - he, angeblich bildet ihr die Realität ab - da sind aber sehr wohl Kreise und Kurven vorhanden.

Aus mathematischer Sicht ist die Sache ausgiebig beschrieben und wohl hunderte Male in verschiedenen Anwendungen implementiert. Vorteilhaft ist sie ja bekanntermaßen auch.
Gibt es eine höhere Macht über uns die sagt “no way”, oder ist es einfach die Trägheit der Masse die dazu führt, dass wir nur bei Punkt und Polylinie bleiben müssen?

Grüße,
Marek

Für die Kurve braucht es ja 3 Punkte auf der Kurve, die dann irgendwie zu einer Einheit verschmolzen werden müssen. In der Auswertung macht es mehr Aufwand, weil erst eine Geometrie erzeugt werden muss. Einen Vorteil sehe ich nicht. Ungenauigkeiten weisen beide Methoden auf. Polylinien lassen sich aber deutlich einfacher und intuitiver (sehr wichtig für Neulinge) erstellen als Kurvenabschnitte.

Ich denke die 3 Punkte dürfte noch die sinnvollste Bedingung sein. Krümmungsmittelpunkt und 2 Punkte sind auch nicht besser.

Alle neueren Straßen bestehen aus Kurven.
Die Radien schwanken zwischen 5 und mehreren 100 Metern.
Polygone reichen mMn für beides völlig aus.

Genau deswegen. Die Datenmenge ist wesentlich gerineger, wenn sie aus Kurvenausschnitten besteht, die Visualisierung sieht besser aus.

Während der Auswertung zeichnet man gleich mit einem Kurvenwerkzeug. Beispiel: Kreisel wird mit einem Kreiswerkzeug und 3 Punkten die auf dem Kreis liegen gezeichnet.

Momentan durch OSM verendete Technik ist schlichtweg veraltet. Warum soll ich ein Stadiom mit 20-40-60 oder noch mehr Punkten zeichnen, wenn eine Ellipse ausreicht?

Du brauchst an jedem Schnittpunkt mit anderen Wegen die Punkte zusätzlich sowieso. Wozu dann das Konstrukt Radius/Kurve/Kreis, wenn die Punkte effektiv dadurch nicht wesentlich abnehmen, bzw der Programmieraufwand steigt?

Ausserdem erkennt kein Mapper draussen in der Landschaft wo welcher große Radius in einen sehr großen übergeht.
Innerorts sind die Brüche zwar deutlicher, aber wegen Nutzungen/Parkierungen und deutlich kleineren Übergängen nicht ablesbar, bzw schon krasses micromapping.

Vom Reinprogrammieren/ Einstiegsproblemen für Anfänger will ich garnicht reden.

Jedem Auswerter steht es frei, nach seinem Gusto die Punkte einer OSM-Linie nicht durch Geradenstücke, sondern z.B. mit Bezier-Kurven zu interpolieren.

Hallo MoTaBi,
Du hast in den meisten Punkten Recht:

  • Schnittpunkte mit anderen elementen sind sowieso Punkte. Viele Areas und Gebäude verwenden aber gern Kreisausschnitte, da wäre eine solche Zusatzfunktionalität hilfreich.
  • Reinprogrammieren wird deutlich schwieriger. Absolut richtig
  • Einstiegsprobleme - jajn: es hängt davon aus wie die Usability in einem Editor aussieht. Ich kenne viele CAD Editoren- die Unterschiede in der Handhabung sind gewaltig.
  • Schlaue Kurvenmodeller sind so gebaut, dass der User gar nicht präzise entschieden muß in welchem Punkt die Kurve ihre Biegung verändert.

Hi, Oli-Wan,
Interpolation ist eine verlockende Idee hat aber Haken. Ich kenne solche Versuche - sie funktionieren leider in der Praxis nicht immer so, wie man sich es wünscht :frowning: .
Wenn das so wäre, würde ich das Thema nicht ansprechen.

Aus meiner Sicht ist es nicht so einfach…

Zum einen bestehen viele Straßenabschnitte nicht aus Kurven, sondern aus Klothoiden, mathematisch komplizierte Gebilde mit variablen Radien…

Zum anderen gibt es das Simple-Feature-Modell, das nicht sooo schlecht ist, weil es für viele Anwendungen serh brauchbar ist. Betonung liegt ja auf Simple, also KISS-Prinzip

Außerdem lässt sich mit Geraden die Realität durchaus genau genug abbilden.

Das Problem der Datenmenge, welches in verschiedenen Diskussionen immer wieder genannt wird, sehe ich nicht. Sonst müssten wir aufhören zu mappen :wink:

Grüße
Westwind

Nur weil es grad zum Thema passt:

Plugin “utils2” ermöglich nach Angabe 3er Punkte und mit “Umschalt+c” einen Bogen zu erstellen
Standardmäßig: eine Linie auswählen und “Umschalt+o” ergibt einen Kreis

Zu den Straßen:
Die bestehen ja nicht nur aus Linie-Bogen-Linie , sondern aus Linien-Klothoiden-Bogen-Klothoide-Linie (im einfachsten Fall) - und Klothoiden sind im Straßenbau Elemente bestehend aus “A/R/L” (Parameter, Radius, Länge): Sollen die dann in weiterer Folge auch aufgenommen werden? (Schließlich geht es ja bei dem Thema um die Korrekte Darstellung von Straßen - und keinen Annäherungen… :wink: )

EDIT: Orthographie
EDIT2: Verdammt, Westwind war schneller…

Mathematisch gesehen sind Klothoiden auch Kurven, genauso wir Kreisbögen die im modernen Straßenbau ebenfalls verwendet werden.

Somit würde man mit Bezier-Kurven oder ähnliches auch nur eine Annäherung haben, genauso wie es jetzt auch schon ist.

Wie gibt man hier die Anzahl der interpolierenden Punkte an?

Hallo Westwind,
danke dass Du Klothoiden ansprichst, für Viele ist das Thema wohl unbekannt. Vielleicht magst Du das Thema der Community weiter erläutern, mir ist die Thematik seit 11 Jaren im Detail bekannt.
Berücksichtigt man auch die Klothoiden, kommt man zu einer weiteren Reduktion der Datenmenge. Dabei geht es nicht um ein Problem mit der Datenmenge die sich auf auf dem Server befindet, denn Du hast Recht, wenn du schreibst, dass wir das nicht als Problem ansehen sollten, sondern z.B um die Verbesserung der online Datenübertragung von dem Server.
Und natürlich auch um Micromapping.

Selbstverständlich gibt es hier Pros und Cons. Eigentlich ist es ein schönest Thema für eine Studienarbeit die Beides untersucht. Solane wir das nicth ausprobiert haben, werden wir zu keinem Schluß kommen können, denn das die momentane Lösung funktioniert und für viele Anwendungsfälle und die meisten Menschen ausreicht, ist ja klar.

F12 > Links unten Haken rein bei “Expertenmodus” > “Einstellungseinträge direkt setzen” (das Symbol mit Papier und Schraubenschlüssel) > in der “Suche” (Zeile oben) “circ” eingeben

Die gefilterte Liste wirft nun unter anderem “createcircle.nodecount” aus. Dort den gewünschten Wert eintragen > JOSM neustarten
Der weitere Wert “curves.circlearc.angle-separation” regelt die Erstellung der Kreisbögen.

Das Problem mit der Bezier-Kurven ist, dass sie nur eine Aproximation darstellt und somit nicht durch die Stützpunkte geht. Für eine halbwegs korrekte Darstellung von einer Polylinie müsste man schon auf ein Interpolationsverfahren zurückgreifen (z.B.: Spline).

Stimmt Jimmy_K.
Da wir nicht allein auf dieser Welt Karten machen, wäre das ein klarer Vorteil für OSM.

Für das Rendering allein mag das ja alles noch Sinn ergeben - sofern man dabei Kurven zeichnen kann.
Was man aber nicht vergessen darf, ist, dass wir aus den Daten alles mögliche erzeugen. Wie bringe ich bspw. einem Navi (bspw. Garmin) die Kurven bei? Genau, gar nicht. Ich muss sie erst in Geradenstücke auflösen. Möchte man die Daten für Routing nutzen, muss man auch zumindest die Kurvenlänge berechnen. Für sämtliche statistischen Auswertungen auch. Reverse Geocoding muss die Kurve auch irgendwie auflösen.
Meiner Meinung nach sind damit einige Probleme verbunden. Die relativ kleinen Vorteile an manchen Stellen (wie geschrieben wurde reduziert die Realität die Idealfälle durch Klothoiden, Verbindungen in der Kurve, etc) sind mir nicht groß genug, um den Aufwand zu rechtfertigen. Effektiv würde man damit manchen Renderern helfen und die zu transportierende Datenmenge leicht senken. Dafür muss jeder “Empfänger” aber mehr rechnen.

Das wurde u.a. vor drei Jahren hier diskutiert:

http://lists.openstreetmap.org/pipermail/dev/2009-March/014262.html

U.a. kam dabei auch ein Patent von Navteq zur Sprache, das eventuell eine Rolle spielt.

Insgesamt denke ich, dass Kurven als “Zusatzfeature” interessant sein koennten, aber dass man auf absehbare Zeit nicht damit rechnen sollte, dass jeder Client damit auch etwas anfangen kann. Das Argument “Datenmenge kleiner” wuerde also nicht ziehen.

Bye
Frederik

Ich sag´s mal so: irgend jemand muß den Stein als erster bewegen: rollt der ert mal, dann wird es auch Bauteile geben, die so programmiert sind, dass die Kurven unterstützt werden. OSM hat mittlerweile eine gewaltige Macht. Den meisten von uns ist es eben noch ein wenig unbekannt.

Ja, es gibt einige Patente in diesem Umfeld, nicht nur von Navteq, was OSM aber anstreben würde ist eine generelle verwendung der Kurvenelemente zum Zeichnen der Linien und Oberflächen und das ist seit dem Anfan der 90-er Stand der Technik und somit nicht patentierbar.

Der Vorteil ist schon real. Die Entwickler von X-Plane beispielsweise verwenden OSM und approximieren unsere Ways vorher durch Bezier-Kurven, unter anderem um Speicherplatz zu sparen:
http://developer.x-plane.com/2011/08/bezier-curved-roads-from-osm/

Natürlich wäre das Resultat besser, wenn man es andersherum machen würde: Kurven mappen und bei Bedarf in Anwendungen durch Polygonzüge approximieren. Die Darstellungsqualität könnte auch davon profitieren. Denn momentan zeichnen die meisten Mapper halt so, dass man auf der Karte in üblichen Zoomstufen keine gar zu sehr sichtbaren Ecken bekommt. Beim 3D-Rendering merke ich es aber schon hin und wieder.

Insofern fände ich es interessant, aber eine wichtige Herausforderung ist schon der Umgang in den Editoren. Schließlich muss OSM unbedingt einfach zu editieren sein. Es wäre auf jeden Fall eine sanfte Einführung nötig, die es Clients ohne entsprechendes Feature erlaubt, trotzdem mit den Daten umzugehen.

Gerade Linien sind auch nur lineare Bezier-Kurven. Quadratische und Kubische Bezier-Kurven find ich noch ziemlich intuitiv zu bearbeiten.
Wie das dann mit Klothoiden und editieren aussieht weiß ich nicht.

Es ist halt die Frage, was man erreichen will. Ich denke, dass für die meisten Anwendungen Approximation durch Bezier-Kurven ausreichen würde.