Integration der Kurvendarstellung in OSM

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.

Alle neueren Straßen bestehen aus Kurven.

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

In der Auswertung macht es mehr Aufwand, weil erst eine Geometrie erzeugt werden muss.

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.

marek kleciak wrote:

die Visualisierung sieht besser aus.

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 🙁 .
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 ;-)

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... 😉 )

EDIT: Orthographie
EDIT2: Verdammt, Westwind war schneller...

Westwind wrote:

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...

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.

tunnelbauer wrote:

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

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.

Wie gibt man hier die Anzahl der interpolierenden Punkte an?

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.

marek kleciak wrote:

Ein guter Freund von mir fragte, warum wir eigentlich keine Kurven in OSM verwenden.

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

http://lists.openstreetmap.org/pipermai … 14262.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.

Westwind wrote:

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

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/be … -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.

hofoen wrote:

Westwind wrote:

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...

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.

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.

Ihr wollt jetzt aber nicht wirklich, dass sich ein Anfänger in OSM mit Klothoiden rumschlagen muss?
Und diejenigen die Eisenbahnen kartieren sind dann auch noch mit Lemniskaten konfrontiert?

Sorry - aber da verlassen wir dann mit OSM eine "crowdgeseourcete" Karte und bewegen uns hin in Richtung Trassierungskarte für Profis.
Das wollte OSM doch nie werden, oder? (also: Keep it simple - und bleiben wir bei Linien)

Für "rundere" Übergänge gibt es zB in Mapnik die Codierung "<CssParameter name="stroke-linejoin">round</CssParameter>" - dort anzusetzen wäre für "schönere" Ergebnisse einfacher...

Hallo Thomas,
in dem Augenblick, wo uns sehr detaillierte Luftbilder von einer Gegend vorliegen, können Anfänger durchaus die Uferkante eines Teiches mit einer Kurve nachzeichnen. Dem User wird eben eine Option mehr zur Verfügung stehen. Wir haben jetzt schon in OSM einige Themen wo die Einstiegshürden relativ hoch sind. Und einige Leute lernen es mit der Zeit und einige nie.
Das Zeichnen von Kreisen, Ellipsen usw. wird von den Laien genauso schnell begriffen, wie das Zeichnen von Linien.

Ich glaube, ich muß einige Beispiele in die Wiki einbauen, denn um die Codierung die Du ansprichst, hgeht es hier nicht - es geht um bessere Darstellung vor allem in den höchsten Zoomstufen.

In den höchsten Zoomstufen von was?

tunnelbauer wrote:

Sorry - aber da verlassen wir dann mit OSM eine "crowdgeseourcete" Karte und bewegen uns hin in Richtung Trassierungskarte für Profis.
Das wollte OSM doch nie werden, oder? (also: Keep it simple - und bleiben wir bei Linien)

Natürlich wäre eine vernünftige GUI unverzichtbar, aber das ist zumindest bei Kurvenformen, für die es gängige GUI-Metaphern gibt - etwa Bezier-Kurven mit ihren Anfassern - keine unlösbare Herausforderung. So ziemlich alle Zeichenwerkzeuge in gängigen Programmen von Inkscape bis Libre/OpenOffice haben Kurvenfunktionen. Es scheint also durchaus etwas zu sein, was man Endnutzern "zumuten" kann, wenn man es richtig macht.

Ich glaube nicht, dass wir kurzfristig Kurven in OSM sehen werden, aber ich sehe auch keinen Grund für eine Fundamentalopposition gegen diese Idee.

Für "rundere" Übergänge gibt es zB in Mapnik die Codierung "<CssParameter name="stroke-linejoin">round</CssParameter>" - dort anzusetzen wäre für "schönere" Ergebnisse einfacher...

Das hat mit Kurven nichts zu tun, das ist nur eine andere Darstellung der trotzdem vorhandenen Ecken. Und macht auch eckige Ecken "rund"...

In den höchsten Zoomstufen von was?

von der 2D Karte. In der 3D Darstellung wäre es auch hilfreich.

Grüße,
Marek

Tordanik wrote:

Ich glaube nicht, dass wir kurzfristig Kurven in OSM sehen werden, aber ich sehe auch keinen Grund für eine Fundamentalopposition gegen diese Idee.

Sehe ich ähnlich. Neben einer GUI-Umsetzung braucht es aber dafür einen neuen Datentyp.

Nichtmal unbedingt sofort. Wenn wir eine Darstellung nehmen, in der die Kurve die eingetragenen Stützpunkte alle schneidet und nicht nur wie bei den Bezier-Kurven als Kontrollpunkte nutzt, dann würde es zumindest für den Anfang ein way mit zusätzlichem Tag wohl tun, ohne sämtliche nicht darauf vorbereiteten Auswertungen kaputt zu machen.

So...ich hab mal ein wenig den Gedanken freien Lauf gelassen.

Wenn man davon ausgeht, dass Kurve=Kreisbogen, ist es mit dem Datentyp curve recht simpel.

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'>
<node␣id='1'␣lat='...'␣lon='...'␣/>
<node␣id='2'␣lat='...'␣lon='...'␣/>
<node␣id='3'␣lat='...'␣lon='...'␣/>
<curve␣id='1'␣>
<nd␣ref='3'␣/>␣//Startpunkt
<nd␣ref='2'␣/>␣//Hilfspunkt
<nd␣ref='1'␣/>␣//Endpunkt
</curve>
</osm>

Also egtl. ein wie ein Way nur mit genau 3 Nodes. Als kleine Demo hab ich es mal für einen Straßenabschnitt fix umgesetzt (trunk auf Mapnik-Primary, damit man es besser sieht):

Damit josm mit den Daten klar kommt, hab ich den Datentyp bei way belassen, zum Nachvollziehen aber curve=yes getaggt und den Hilfspunkt mit curve=middle getaggt. Beides ist mit dem Datentyp curve (siehe oben) nicht nötig.

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣upload='true'␣generator='JOSM'>
<node␣id='-58'␣action='modify'␣visible='true'␣lat='50.97624267299224'␣lon='11.284868318566938'␣/>
<node␣id='-56'␣action='modify'␣visible='true'␣lat='50.977472509120204'␣lon='11.28845722585104'␣/>
<node␣id='-54'␣action='modify'␣visible='true'␣lat='50.98111183334305'␣lon='11.291720590660256'␣/>
<node␣id='-52'␣action='modify'␣visible='true'␣lat='50.98141676376676'␣lon='11.291657070177354'␣/>
<node␣id='-50'␣action='modify'␣visible='true'␣lat='50.98317132450159'␣lon='11.292062013255869'␣/>
<node␣id='-48'␣action='modify'␣visible='true'␣lat='50.98435599040213'␣lon='11.292284334946036'␣/>
<node␣id='-46'␣action='modify'␣visible='true'␣lat='50.98523072430183'␣lon='11.292284334946036'␣/>
<node␣id='-44'␣action='modify'␣visible='true'␣lat='50.987679891534434'␣lon='11.291180666555572'␣/>
<node␣id='-42'␣action='modify'␣visible='true'␣lat='50.989524179113495'␣lon='11.289394152973882'␣/>
<node␣id='-40'␣action='modify'␣visible='true'␣lat='50.99463182341778'␣lon='11.291188606615933'␣/>
<node␣id='-38'␣action='modify'␣visible='true'␣lat='50.99615101423253'␣lon='11.294801334081122'␣/>
<node␣id='-36'␣action='modify'␣visible='true'␣lat='50.998042099052995'␣lon='11.29783956551705'␣/>
<node␣id='-34'␣action='modify'␣visible='true'␣lat='50.99984412350129'␣lon='11.30159003182825'␣/>
<node␣id='-32'␣action='modify'␣visible='true'␣lat='51.00016918712704'␣lon='11.30342034921964'␣/>
<node␣id='-30'␣action='modify'␣visible='true'␣lat='51.000416516620994'␣lon='11.304262519798504'␣/>
<node␣id='-28'␣action='modify'␣visible='true'␣lat='51.00187926695615'␣lon='11.309214482802213'␣/>
<node␣id='-26'␣action='modify'␣visible='true'␣lat='51.00249403231801'␣lon='11.31265053876397'␣/>
<node␣id='-24'␣action='modify'␣visible='true'␣lat='51.00130689188247'␣lon='11.30663182636037'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-22'␣action='modify'␣visible='true'␣lat='51.00026433469981'␣lon='11.303872231459675'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-20'␣action='modify'␣visible='true'␣lat='50.999219988940716'␣lon='11.29937815729419'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-18'␣action='modify'␣visible='true'␣lat='50.99705127241943'␣lon='11.296710297012199'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-16'␣action='modify'␣visible='true'␣lat='50.992198776887136'␣lon='11.288524094777891'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-14'␣action='modify'␣visible='true'␣lat='50.98665101830255'␣lon='11.292033601458362'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-12'␣action='modify'␣visible='true'␣lat='50.9836819453887'␣lon='11.292176522544896'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-10'␣action='modify'␣visible='true'␣lat='50.98237229395303'␣lon='11.29166835868166'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<node␣id='-8'␣action='modify'␣visible='true'␣lat='50.97900302087013'␣lon='11.29141427675004'>
<tag␣k='curve'␣v='middle'␣/>
</node>
<way␣id='-90'␣action='modify'␣visible='true'>
<nd␣ref='-58'␣/>
<nd␣ref='-56'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-88'␣action='modify'␣visible='true'>
<nd␣ref='-30'␣/>
<nd␣ref='-24'␣/>
<nd␣ref='-28'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-86'␣action='modify'␣visible='true'>
<nd␣ref='-28'␣/>
<nd␣ref='-26'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-84'␣action='modify'␣visible='true'>
<nd␣ref='-32'␣/>
<nd␣ref='-22'␣/>
<nd␣ref='-30'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-82'␣action='modify'␣visible='true'>
<nd␣ref='-34'␣/>
<nd␣ref='-32'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-80'␣action='modify'␣visible='true'>
<nd␣ref='-36'␣/>
<nd␣ref='-20'␣/>
<nd␣ref='-34'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-78'␣action='modify'␣visible='true'>
<nd␣ref='-38'␣/>
<nd␣ref='-18'␣/>
<nd␣ref='-36'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-76'␣action='modify'␣visible='true'>
<nd␣ref='-42'␣/>
<nd␣ref='-16'␣/>
<nd␣ref='-40'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-74'␣action='modify'␣visible='true'>
<nd␣ref='-40'␣/>
<nd␣ref='-38'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-72'␣action='modify'␣visible='true'>
<nd␣ref='-46'␣/>
<nd␣ref='-14'␣/>
<nd␣ref='-44'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-70'␣action='modify'␣visible='true'>
<nd␣ref='-44'␣/>
<nd␣ref='-42'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-68'␣action='modify'␣visible='true'>
<nd␣ref='-50'␣/>
<nd␣ref='-12'␣/>
<nd␣ref='-48'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-66'␣action='modify'␣visible='true'>
<nd␣ref='-48'␣/>
<nd␣ref='-46'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-64'␣action='modify'␣visible='true'>
<nd␣ref='-52'␣/>
<nd␣ref='-10'␣/>
<nd␣ref='-50'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-62'␣action='modify'␣visible='true'>
<nd␣ref='-54'␣/>
<nd␣ref='-52'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
<way␣id='-60'␣action='modify'␣visible='true'>
<nd␣ref='-56'␣/>
<nd␣ref='-8'␣/>
<nd␣ref='-54'␣/>
<tag␣k='curve'␣v='yes'␣/>
<tag␣k='highway'␣v='primary'␣/>
</way>
</osm>

Evtl. hat ja jemand auch an dem Thema Interesse und die Kenntnisse einen kleinen Renderer zu schreiben, der das umsetzen würde, oder hat bessere/andere Vorschläge zu dem Thema.

wow,
nicht schlecht!
Ist es möglich einige weiter Beispiele zu generieren? Höhere Zoomstufe, z.B für eine Uferkante oder z.B sowas: http://osm.org/go/zmpVkrSru-

Machte es Sinn diesen Thread unter allg. Entwicklunsthemen zu platzieren?

Viele Grüße,
Marek

Nuja...den Anstieg manuell zu berechnen ist bestimmt nicht einfach, zumindest nicht mit den Werkzeugen, die josm so zu bieten hat. Da bräuchte man schon Hilfsmittel ala Spline-Werkzeug, die Tordanik schon angesprochen hat. Dann wäre es sicherlich auch sinnvoll möglich mehr ins Detail zugehen. Zumal man ohne Visualisierung nicht sonderlich viel sieht.

Unter allgemeine Entwicklung passt es denke ich besser als hier in den deutschen Teil des Forums.

EDIT: Ohne visuelles Feedback ist es beim Erstellen auch eher Glück, die Kurve richtig zu treffen. Wenn der Editor aber dem Mapper immer die aktuelle Kurvenform auf das Luftbild/gps-Track zeichnet ist das natürlich relativ einfach zu mappen.

Ein Vorteil der Kurven wäre bspw. auch, dass der Auswerter den Detailgrad bestimmen kann. Wenn das Garminformat zum Beispiel nur 5m-Raster unterstützt hilft es dem Auswerter wenig, wenn der Mapper eine Linie mit 1m-Wegsegmentlänge mappt, eher im Gegenteil.

Für variable Kurven (Splines) bräuchte man mindestens zwei Punkte die Start und Ende definieren. Für jeden dieser Punkte bräuchte man noch zwei Hilfspunkte, die die Form des Splines beeinflussen.

Hier mal ein kleines Beispielbild mit 3 Punkten. Am Punkt 2 sieht man die beiden Hilfspunkte 2L und 2R.

Im Datenmodell kann man das bspw. wie folgt umsetzen:

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'>
<node␣id='1'␣lat='...'␣lon='...'␣/>
<node␣id='2'␣lat='...'␣lon='...'␣/>
<node␣id='3'␣lat='...'␣lon='...'␣/>
<curve␣id='1'␣>
<nd␣ref='1'␣L_lat='...'␣L_lon='...'␣R_lat='...'␣R_lon='...'␣/>␣//Startpunkt
<nd␣ref='2'␣L_lat='...'␣L_lon='...'␣R_lat='...'␣R_lon='...'␣/>␣//Zwischenpunkt
<nd␣ref='3'␣L_lat='...'␣L_lon='...'␣R_lat='...'␣R_lon='...'␣/>␣//Endpunkt
</curve>
</osm>

Als Nachteil sehe ich hier erstmal, dass es mehr Speicher benötigt, als ein Kreisbogen (ist natürlich kein wirkliches Argument). Dafür ist man natürlich deutlich flexibler was die Form angeht. Außerdem ist man flexibler was die Punkteanzahl angeht, was nicht gerade unerheblich ist, wenn man an Straßen und dessen Einmündungen denkt.

Bei Änderungen (Verschieben) an einem Node wirken sich die Änderungen auch auf die Hilfspunkte (2L, 2R) aus, sodass es sinnvoll wäre, dessen Koordinaten relativ zu den Koordinaten des Bezugspunktes (2) zu speichern. Dann müssen bei einem Verschieben keine Änderungen an der curve vorgenommen werden, sondern es ist ausreichend, die Koordinaten des Nodes zu ändern.

Die User aus der Russischer Community weisen auf Problembereiche hin: "Cubic curve geometry on a geoid is not simple. Note, it is not only rendering, but also angle, length, area computation, hit tests, intersections..."

Was glaubt Ihr - machbar / nicht machbar?
Grüße,
Marek

Nunja...für Berechnungen muss man immer eine lineare Interpolation machen. Ich auch keine Ahnung, wie rechenaufwändig so eine Interpolation ist. Letztlich sind die Kurven nur für die "hübschen Bilder" und die variable Genauigkeit der Auswertung sinnvoll. Bei der Interpolation kann der Auswerter frei die Auflösung festlegen. Der simple Fall wäre eine lineare Verbindung der Nodes. Für den Rest muss man eine Interpolation machen. Wobei man das natürlich auch zentral machen könnte.

marek kleciak wrote:

Die User aus der Russischer Community weisen auf Problembereiche hin: "Cubic curve geometry on a geoid is not simple. Note, it is not only rendering, but also angle, length, area computation, hit tests, intersections..."

Stimmt schon, wenn man nicht in der Ebene rechnet, hat man mit Kurvenformeln eine ziemliche Herausforderung vor sich. Ich wäre jetzt davon ausgegangen, dass das schlicht vernachlässigt wird. Denn genau das tun die meisten Programme mit unseren derzeitigen Ways ja auch. Da werden einfach die Node-Koordinaten projiziert und dann eine gerade Linie auf dem Bildschirm gezeichnet. Unsere Ways sind normalerweise zu kurz, als dass der Effekt der Erdkrümmung in irgendeiner Weise auffällt.

Der Hinweis auf Schnittberechnungen etc. ist allerdings richtig. Wenn man die Einstiegshürden für Anwendungsentwickler nicht zu hoch legen will, müsste man praktisch zwangsläufig schon vorab linear interpolierte Daten bereitstellen. Dummerweise kann das durchaus zu Verfälschungen bei den genannten Tests führen (die Kurven schneiden sich, die Interpolationen nicht mehr).

Insgesamt macht das alles die Sache aber schon recht problematisch und ist von daher - wenn ich so drüber nachdenke - wahrscheinlich den Aufwand momentan wirklich nicht wert.

Was glaubt Ihr - machbar / nicht machbar?

Machbar, aber sehr aufwendig. Ich würde mir wohl erstmal andere Baustellen suchen.

Leute was habt ihr alle mit euren Bezier-Kurven? Bei diesen Kurven geht die Gerade nicht durch die Stützpunkte und somit ist es mit dem aktuellen System inkompatibel!

EDIT: Da habe ich wohl Seite 2 übersehen. Entschuldigt bitte!

Zumindest meine Ausführungen beziehen sich auf Kreisbögen bzw. Splines.

Ich beziehe mich auf die Zeichnung oben:
Würde man an dem Punkt 1 zusätzlich Hilfspunkt 1R und an dem Punkt 3 Hilfspunkt 3L haben, wäre der Verlauf einer komplexen Kurve stetig.

Ich betrachte das Ganze mal aus der Sicht eines Editors (bzw dessen Benutzer):
- Wie fügt man in so eine Kurve einen zusätzlichen Punkt ein (z.B. für einen abzweigender Weg)? Gibt es dann zwei Kurven oder eine Kurve und eine Gerade?
- Was passiert wenn ein Punkt der Kurve gelöscht wird? Haben wir dann ähnliche Probleme wie bei den Abbiegebeschränkungen, die auch aus genau 3 Elementen bestehen müssen?

Ich fürchte mich etwas vor der Komplexität und den möglichen Fehlerquellen.

Wie wäre es denn mit natürlichen kubischen Splines. Die würden durch alle vorhandenen Stützpunkte verlaufen, wodurch Kreuzungspunkte erhalten blieben und bräuchten keinerlei zusätzlichen Nodes. Es wäre lediglich zu markieren ob ein Way als Polygonzug oder als Spline gerendert werden soll. Der Renderer hätte dann allerdings das Problem für jede Kachel den gesamten Spline zu berechnen weil es sonst an den Kachelgrenzen zu Ungenauigkeiten kommen würde.

@mdk:

Ich hatte ja oben zwei Beispiele gepostet, wobei ich denke, dass die Splines sinnvoller sind. Eben weil es keine Probleme gibt mit der Anzahl der Punkte. Vom Editieren ist es ähnlich wie bei einem Weg jetzt auch. Für die Spline braucht man weniger Nodes (in vielen Fällen nur Start und Ende), dafür aber die angesprochenen Hilfspunkte zu jedem Node, die die Form der Spline beeinflussen.

In der Spline können beliebig viele Punkte sein, so wie in den Ways derzeit und an jeden dieser Punkte kann ein neuer Weg starten, wie bei den ways heute. Man könnte auch sagen, der Way ist eine lineare Spline.

@ieichens:

Der Renderer könnte sich vorher auch eine Interpolation erzeugen, bspw. einen normalen Way, mit einem Nodeabstand von 1m oder 10cm oder wie genau er es gerne hätte. Was nun sinnvoller ist kann ich nicht abschätzen.

Warum behandelt man nicht einfach alles als Ellipse? Jede gerade Linie hat zwei Punkte an denen je eine Linie weiter geht. Hier kann man den jeweiligen "Folgewinkel" ausrechnen und somit entscheiden, daß es eine Ellipse ist und diese so zeichnen, daß sie zur Folgeellipse perfekt passt. (Wenn ein Node mehr als zwei Linien hat, ist es keine Kreuzung und die geht mit 0° in die Berechnung ein.) (Streng genommen sind es natürlich keine vollen Ellipsen, sondern nur jeweils Teil davon)

Und schon hat man perfekt geformte Straßen. Ohne Zusatztags. Natürlich sind die nicht 100%ig richtig, aber 90%ig auf jeden Fall. Man hätte in Mapnik keine Ecken und Kannten mehr und würde automatisch mit viel weniger Nodes arbeiten.

Es müsste nur irgend jemand anfangen einen Test-Renderer zu schreiben, der zeigt wir gut sowas funktioniert. Wenn dann Mapnik und JOSM folgen, ist "es" geschafft.

Gefällt einem die Kurve nicht, fügt man einfach einen Node an der "Schlechtesten" stelle ein und verschiebt den richtig. Und schon ist die Kurve perfekt.

Klingt erstmal auch interessant. Könntest du das mal in eine Grafik packen, damit man sieht, was du meinst?

So habe ich mir das gedacht:

Kreuzungen und Links-Rechts-Änderungen sind oben noch nicht beschrieben, aber hier müsste etwas ähnliches möglich sein.

Wo ich jetzt spontan das Problem sehe ist, dass man keinen sinnvollen Übergang zu Geraden hinbekommt. Also wenn die erste blaue Linie und die letzte blaue Linie normale Ways wären und das mittlere Stück die Kurve. Wenn der Nutzer dann wieder mit vielen Nodes tricksen muss, hätte man nicht viel gewonnen.

Das wäre ja dann ein ähnliches Smoothing Verfahren welches beim Osmarender verwendet wurde.
Oft hat es gepasst allerdings manchmal zu komischen Effekten geführt.

Wenn ich wirklich eine echte lange gerade habe, sind hier am Ende zwei Nodes erforderlich, ja. Aber es ist besser als 20 Nodes in der Kurve.

Dann finde ich aber den Spline doch sympathischer, als bei 'echten langen Geraden' (und die haben wir ja nun doch nicht so selten, nicht) dann jeweils zwei Endpunkte machen zu müssen. Das ist dann zu unintuitiv, zumindest für meinen Geschmack.

Wobei, eine Gerade auch dann eine Gerade ist, wenn sie drei Punkte hat. Das wird sich zum Großteil von alleine erledigen. Da wo es das nicht macht, setzt man einfach einen neuen Node und schiebt den an die richtige Stelle und dann hat es sich erledigt.

Dennis, derzeit denke ich auch, dass man mit Splines besser fahren dürfte. Zum einen ist deren Verwendung intuitiver und zum anderen dürfte es dazu mehr Algorithmen geben.

Jetzt will ich doch auch mal noch ein paar Gedanken in diesen Thread einbringen. Der Thread mischt ja sehr stark zwischen Eingabe, Datenspeicherung und Ausgabe (Rendering), daher versuche ich da mal etwas zu differenzieren.

Persönlich finde ich (B-)Splines sehr schwer zu bedienen. Auch wenn sie bei Eingabe die gemalten Kontrollpunkte interpolieren finde ich es meist sehr unintuitiv und schwer den eigentlich gewünschten Kurvenverlauf zu erhalten. Habe ich hingegen Beziersplines (in typischen Anwendungen vom Grad 2 oder 3) so habe ich zwar keine Interpolation an den Kontrollpunkten sondern die "Konvexe-Hülle-Eigenschaft", ich zumindest komme mit sowas wesentlich leichter zurecht.

Am einfachsten finde ich bei Eingabe aber immer noch den linearen Spline (der Polygonzug 😉). Den kann ich so genau machen wie ich will oder auch nicht und wenn ich es "kurviger" will dann kann man die Daten auch aufbereiten und eine Approximation der Daten mit einem entsprechenden Spline durchführen.

Bzgl. der Datenspeicherung sehe ich zwar prinzipiell eine Möglichkeit der Datenreduktion, aber diese vor allem bei einer automatisierten Approximation der Basisdaten. Ich befürchte, dass bei direkter Eingabe von Splinekontollpunkten die Benutzer für schöne Kurvenverläufe auch entsprechend viele Punkte setzen würden und sich die Datenbasis nicht wirklich verringert. Hier habe ich aber bzgl. manuellen Eingaben keine Erfahrung.

Bei der Ausgabe (und auch bei Eingabe) sollte aber ein sehr wichtiger Punkt beachtet werden: Ein Großteil der Splinetypen (z.B. die Beziersplines) kann man nicht "offsetten". Genau das will ich aber an vielen Stellen in OSM erreichen: Z.B. will ich zwei Bahnlinien oder auch die zwei Spuren einer Autobahn parallel halten und genau das kann ich mit den meisten Splines nicht! Ähnliche Probleme treten dann auch auf, wenn ich z.B. eine Straßenbrücke habe (die Brückengeländer sollten ja Offsets der Straße sein) usw usf. Wenn ich mich recht erinnere sind das die Probleme die chris66 angesprochen hat (das Pythonskript für Osmarender um die Polygone durch Bezierkurven zu approximieren).

Ich habe mir selbst noch keine Meinung gebildet ob ich "Kurven" für OSM gut fände oder nicht. Aber wenn Kurven dann würde ich aus meiner beruflichen Erfahrung heraus klar Kreisbogensplines bevorzugen. Den Ansatz von aighes fand ich da sehr schön. Für Kreisbögen kann man dann auch Offsets bilden, man kann sie einfach glatt anschließen lassen, man kann sie leicht unterteilen, die Abstandsberechnung ist so einfach wie für ein Polygon,... Nur die Repräsentation in der Datenbasis würde ich vermutlich anders angehen und statt dem Kontrollpunkt lieber einen "Radius" angeben wo das Vorzeichen der "Krümmungsrichtung" entspricht. Man könnte dann auch festlegen, dass der Radius einen Mindeswert haben muss, so dass man eine "Abwärtskompatibilität" erhält indem man einfach nur eine Linie von Start- zu Endpunkt malt.

Edit: Was mir gerade noch einfällt/auffällt: Wenn ich ein Polygon mit n Linien habe brauche ich ja bekanntlich n+1 Koordinaten zum Speichern. Habe ich einen glatten Kreisbogenspline aus n Bogenstücken dann reichen mir n+1 Koordinaten mit nur einem zusätzlichen Doublewert. Und zwar kann ich das erste Bogenstück über Startpunkt, Endpunkt und Radius beschreiben. Für das nächste Bogenstück ist der vorherige Endpunkt der neue Startpunkt, die Tangente kenne ich wegen dem glatten Anschluss und durch den nächsten Punkt ist das Bogenstück bereits definiert. Durch ein zusätzliches Attribut an einen Way (den Radius des ersten Bogens) kann ich daher einen kompletten glatten Kreisbogenspline definieren 🙂