Es kommt doch eigentlich selten vor, dass wege wirklich eckig sind, also richtige Knicke haben.
Meistens ist es doch so, dass wege geschwungen sind, also durchgehend differenzierbar.
Nun stellt sich mir die Frage, ob es nicht besser wäre, die Wege einfach mit einem Tag zu kennzeichnen, so dass Renderer automatisch interpolieren und die Wege zwischen den Punkten wirklich Rund zeichnen.
So könnte man sich viele Punkte einfach sparen, weil es egal ist, ob die Punkte vom Tagger interpoliert eingetragen werden oder ob es gleich der Renderer macht, der es dann echte Rundungen zeichnen kann.
Ich würde mir wünschen, dass die Editoren das unterstützen würden, also dass man im Editor gleich kurven einzeichnen () kann und der Editor dann nur die notwendigen Punkte setzt.
So bräuchte man für kreisförmige gebilde nur 2-4 Nodes und es besteht nicht die Gefahr, dass jemand dann den Weg vereinfachen kann.
Sind euch schon solche Tags vorgekommen?
Ansonsten, könnte man solche einführen?
z.B. in Dortmund probehalbe einsetzten?
die meisten renderer interpolieren automatisch.
bei den editoren ist dies jedoch nicht der fall. und das ist auch richtig so. schliesslich will man ja wissen und auch richtig sehen können, wo die bestehenden punkte gesetzt sind um gegebenenfalls Anpassungen vornehmen zu können. Würde ein Editor auch interpolieren, wäre recht schwierig Anpassungen vorzunehmen.
Ist mir bisher noch nie aufgefallen. Jedenfalls sind bei Mapnik alle Wege, sogar Kreisverkehre kantig.
Bei Mapnik ist mir noch nie eine echte Kurve untergekommen.
Hast du ein Gegenbeispiel?
Bei JOSM stelle ich mir das so vor:
Man aktivier bzw. deaktivier die Option “Interpolierte Wege generieren”
Dann kann man wie gewohnt die Wege zeichnen, nur dass nach dem setzten eines Punktes der Weg rund (durch den aktuellen und 2 vorige Punkte interpoliert) angezeigt wird.
Passt ein die Rundung nicht, dann passt man sie an. Das + auf der Rundung anklicken und somit einen weiteren Punkt einfügen, wodurch dann die Kurve entsprechend verfeinert wird.
So könnte man gleich sehen, ob das Interpolierte Ergebnis stimmt, z.B. wenn man in Dortmund von Aerowest abpaust.
o.k. habe es falsch geschrieben… “in gewissem masse” wird es von den meisten renderer interpoliert. mapnik ist da aber defintiv davon ausgeschossen - da wird nichts interpoliert (jedenfalls nicht in hoher zoomstufe). aber z.b. osmarender hingegen interpoliert auch in höchster zoomstufe noch ein bisschen.
Ein Tag auf dem Weg “Dieser Weg hat einen Radio von 20 Metern bis zum nächsten Punkt” wäre sicher sinnvoll um nur Punkte zu sparen. Notwendig wäre das aber nicht.
Vorteile:
Man kann perfekte Kurven mit nur zwei Punkten zeichnen
Nachteile:
Kaum eine Kurve in Deutschland ist Perfekt
Wege müssten an jedem Punkt unterbrochen werden
Das verändern einer Kurve wird komplizierter, wenn z.B. der Startpunkt versetzt ist, kann man am Radius spielen ohne Ende, die Kurve wird zum Teil passen und zum Teil nicht. Das führt dann dazu, dass man die Kurve in mehrere Teile mit verschiedenen Radien einteilt.
Neutrales:
So etwas würde erst ab Zoom 16 und größer Sinn machen. Bei 15 und kleiner sind bereits genügend Punkte vorhanden.
Renderer wären auch heute schon in der Lage zu Interpolieren für die drei Zoomstufen. Wenn viele Wegabschnitte nacheinander ähnliche Winkel zueinander haben, können sie davon ausgehen, daß es eine Kurve ist und nicht ganz so Eckig malen. Wobei Mapnik das nicht macht.
Vorschlag:
Ein Mathematisches Modell ausarbeiten, was Kurven glättet, aber Kreuzungen nicht “beschädigt”, daß Mapnik und co. als Verbessungsvorschlag mitteilen. Damit wären die Zoomstufen 16, 17 und 18 etwas Runder in der Darstellung.
meines Wissens nach existiert dieses Verfahren schon lange und wird auch (zumindest in Deutschland) beim Straßenbau angewendet.
Übergänge zwischen verschiedenen Straßen oder Kurven auf längeren Strecken werden als “Klothoide” angelegt. Das bewirkt einen “sanften, fließenden” Übergang zwischen den beiden Straßen. der Fahrer kann dann sich dann mit gleichmäßigen Lenkbewegungen “durchschlängeln”. Echte Kurven, bestehend aus Stücken mit jeweils konstanten Radien wären da zu ruckelig.
Man (ich leider nicht) könnte ein Tool a la “buildings” in josm schreiben, das 3 markierte Punkte in Fahrtrichtung als Klothoide verbindet und dafür Zwischenpunkte anlegt.
Vom Einbau solcher “Verbesserungen” im Renderer halte ich übrigens garnichts. ansonsten: OMM
Ich halte nicht viel von solchen Automatismen. Das fürht dann später dazu, dass sie wahllos angewendet werden und mehr Schaden angerichtet wird als das es etwas nutzt.
Der Renderer kann mit den Daten machen was er möchte. Meinetwegen auch Loopings bei jedem 3. Node reinzeichnen. Ist dann halt die Frage, ob er dann noch genutzt wird. Extra Tags für eine Verrundung sind aber auch sinnlos, weil man dann auch den Kurvenradius angeben müsste und man diesen nicht einfach bestimmen kann.
ich dachte da eher an eine schlichte kubische Interpolation.
Da muss man nichts weiter angeben, man muss nur den Weg bzw. Wegabschnitt mit einem zusätzlichen Tag markieren, damit Renderer und Editoren wissen, dass die Punkte dieses Wegabschnittes so gewählt sind, dass sie die entsprechende Kurve ergeben.
So treffen dann die von Dennis[ B] genannten Nachteile nicht mehr zu.
Die Kurve könnte dann durch zurätzliche Punkte verfeinert / genauer angepasst werden.
Wenn dieser Interpolationsmarkierung-Tag fehlt, gehen alle Renderer davon aus, dass die Ecken gewollt sind und die Straße wirklich Knicke hat.
Ich finde nach wie vor, daß es sinnvoll sein kann, einem Knoten eine Information mitzugeben, ob er am Schnittpunkt zweier Strecken liegt oder ob er sich auf einer durchgehenden Kurve befindet. Auf der Osmarenderer-Seite über die Bezier-Kurven wird ja auch genau das Problem diskutiert, daß ein Algorithmus von sich aus eigentlich nie wissen kann, ob ein Knick gewollt ist oder nicht.
Mal ein ganz simpler Vorschlag für ein Tag: Wie wäre einfach ein
angle=yes|no
yes= der Knick ist gewollt, der Punkt stellt tatsächlich einen Knickpunkt / Winkel zwischen zwei Strecken dar
no= der Knick ist nicht gewollt, der Punkt liegt auf einer durchgehenden Kurve und die Strecken zwischen den Punkten stellen nur Näherungen der tatsächlichen Kurve dar.
Prinzipiell würde sich das Tag auf einen Knoten beziehen. Damit man nicht jeden Knoten taggen muß, kann man ja sinnvolle Regeln und Standardwerte definieren: Bei Gebäuden wird per default angle=yes angenommen, bei Straßen und anderen ways (Flüsse etc.) per default angle = no. Bei Flächen bin ich mir nicht sicher, was sinnvoll wäre.
Weiterhin halte ich es für sinnvoll, wenn man das Tag auch übergeordneten Objekten geben könnte, z.B. dem Gebäude oder einem Weg, und die Knoten das Tag dann erben würden, es aber auch überschreiben könnten.
Damit wäre der Aufwand de Taggens wohl so gering wie möglich gehalten.
Genau darum habe ich doch beschrieben, was ich mir bzgl. default-Werten und Vererbung des Tags von Ways / Buildings auf die Knoten vorstelle… war das denn so unverständlich ausgedrückt…? Nach meinem vorschlag muß man nur in Ausnahmefällen mal den einen oder anderen Knoten taggen. (Und wenn das dann nicht gemacht wird, ist ja wohl auch kein Schaden entstanden. Wer will, kann das Tag ja eh ignorieren.)
Na ja, natürlich kann man immer irgendwas irgendwie hinkriegen. Das passiert nach meinem Geschmack bei OSM sowieso dauernd und viel zu oft, daß man sich irgendwelche Krücken überlegt, um bloß nichts an den schon Jahre alten ursprünglichen Standards und Methoden zu ändern. Die Frage ist eben, ob man eine grundsätzlich “richtigere” Lösung sucht. Aber das ist halt auch Geschmackssache.
Das ganze muss aber auch sauber bearbeitbar und leicht pflegbar sein. Das sehe ich verdammt kompliziert an, wenn man die Tags noch vererben will. @Philipp: evtl. reden wir auch aneinander vorbei, das ist bei solchen Themen immer möglich. Vorschlag: Male ein Beispiel und biete es als *.OSM-File zum Download an. Dann sieht jeder, wie Du das genau meinst.
Das einzige, was ich mir “leicht bedienbar und mit wenig Arbeit” vorstellen könnt, wäre wenn man einem Weg einfach nen “Kurve=Ja” Tag gibt. Dann können Renderer schöner Zeichnen. Wenn man das ganze Mathematisch definiert (was zwingend erforderlich wäre), ist auch 100%ig sichergestellt, daß alle Renderer gleich arbeiten.
Du hast völlig recht damit, daß es gut zu bearbeiten und zu pflegen sein muß. Ich finde aber, in dieser wie in vielen ähnlichen Diskussionen sollten wir etwas phantasievoller sein, was ein Editor alles leisten könnte. Wir gehen immer vom Status quo aus, in dem ein Editor nicht viel mehr macht als den User eine Key-Value-Liste ausfüllen zu lassen, ergänzt um ein paar Vorlagen. Ein ausgereifter Editor braucht den User aber gar nicht mehr damit zu belästigen, wie und wo welche Information gespeichert wird, sondern erledigt das für den User unsichtbar.
Das ist auch gar nicht kompliziert. Wenn der User einen Punkt editiert, braucht der Editor doch nur nachzusehen, ob der Punkt zu einem Weg gehört, und welche potentiell vererbbaren Tags dieser Weg auf den Punkt vererben würde. Die werden ebenfalls beim Editieren des Punktes angezeigt, ggf. in einer anderen Farbe um zu kennzeichnen, daß das Tag vererbt wurde. Vielleicht auch mit dem Hinweis: "vererbt von Weg xy: " vor dem eigentlichen Wert. Der User kann nun beim Editieren des Punktes wählen: Er vergibt einen expliziten Weg, oder er vergibt keinen Wert und erlaubt damit das Vererben des Tags vom Weg.
Das wäre die einfachste Stufe. Aber was machst Du mit einem Gebäude, was teilweise Ecken und Teilweise Rundungen hat, z.B. den Grundriß eines Halbkreises? Darum finde ich, daß so etwas um extra Tags für abweichende Knoten ergänzt werden muß.
Es müssen nicht alle Renderer gleich arbeiten. Jede mathematische Methode, die man definieren würde, wäre ja rein willkürlich und nicht unbedingt die bei jeder Kurve die realistischste. Eine Kurve in einer Straße kann verschiedene Formen haben, insbesondere außerhalb Ländern wie D, wo es sogar dafür Normen gibt. Und Straßenkurven sehen sicher anders aus als Kurven in Gebäudeumrissen. Daher würde ich das den Renderern überlassen.
Ich habe ein Beispiel hier http://rapidshare.com/files/382046452/Example_angle_curve.osm.html hochgeladen. Dabei ist mir aufgefallen , daß man noch ein zweites Tag braucht, wenn man richtig definieren will, wo eine Kurve in eine Gerade übergeht. Am Beispiel sollte es klar werden, was ich meine: Z.B. ist da ein Gebäude mit einer runden Seite, die dann in eine Gerade Wand übergeht. Ich habe ein solches Tag versuchsweise mal als curve=beginning|end definiert, aber vielleicht kann man das geschickt mit dem anderen Tag zusammenfassen. Es wäre etwas unschön, wenn man für ein Thema zwei Tags bräuchte.
Dann würdest du den Weg einfach auftrennen. Für die Runde seite einen extra Weg und für die extra Seite einen Teil.
Man müsste nur noch das Flächen-Tagging erweitern, so dass mehrere hintereinandergesetzte Wege auch eine Fläche ergeben können.
Ist aber kein Problem, da der Editor das ja einfach automatisch im Hintergrund zu einer Building-/Area-Relation zusammenfassen könnte.
Eigentlich kann man jede Kurve in der Wirklichkeit mit einer kubischen Spline-Interpolation abbildern. Bei speziellen Kurve müsste man eben ein paar Punkte hinzufügen.
Wenn man es genau nimmt, interpolieren auch jetzt schon alle Editoren (linear). Wenn man einen Wegabschnitt für kurveg deklariert, dann wirds eben im Renderer und im Editor auch kubisch interpoliert.
Genau so wie man bei JOSM einen Knick in eine Geraden hinzufügen würde, würde man dann durch einen weiteren Punkt die Kurve verfeinern.
Die Angabe von Radien bei Punkten finde ich nicht überzeugend, da man wirklich jeden Punkt einen Radius hinzufügen würde, was für den Nutzer meiner Meinung nach schwerer zu Erfassen ist (man müsste bei jeder Rundung explizit den Radius bzw. einen Winkel eingeben (grafisch oder nummerisch).
Das wäre eine Möglichkeit. Der Nachteil wäre, daß man solche relations erst mal einführen und definieren müßte, und daß so definierte Flächen vermutlich zu bestehenden Editoren, Renderern usw. nicht abwärtskompatibel wären. Und ich bin auch skeptisch, ob das so viel einfacher wäre als die von mir beschriebene Möglichkeit.
Das mit der Angabe von Radien sehe ich auch als unpraktisch an.
Ich halte gar nichts von irgendeiner Art von manuellem Aufwand um Kurven zu glaetten. Meiner Meinung nach wird das an eben diesem Aufwand scheitern. Ich wuerde diesen Aufwand z.B. schon mal sicher nicht treiben…
Intuitiv wuerde ich sogar sagen, dass der manuelle Aufwand komplett ueberfluessig ist (Hypothese).
Wambacher hat Klothoiden erwaehnt, vgl. z.B. http://de.wikipedia.org/wiki/Klothoide. Da diese offensichtlich im Verkehrswegebau verwendet werden, sollte man auch genau damit Kurven glaetten, und nicht Kubische Splines o.ae. verwenden. In dem zitierten Artikel steht “In den heutigen Trassierungs- und CAD-Programmen ist die numerische Berechnung von Klothoiden in der Programmbibliothek integriert und erfolgt automatisch.”. Also sollte sich das auch in OSM einbauen lassen. Und da man die Loesung kennt, braucht man nur den best fit an die gegebenen Punkte zu berechnen. Das ist meiner Meinung nach der Weg, den man einschlagen sollte. Auch wenn das die Mapper in dieser Hinsicht “arbeitslos” macht. Sorry boys.
Edit: Mit “Einbau in OSM” meine ich Einbau in die Renderer. Die Editoren sollten davon nichts mitbekommen. Ueber die Editoren traegt man weiter Polygonzuege ein.
Extra Tags für eine Verrundung sind aber auch sinnlos, weil man dann auch den Kurvenradius angeben müsste und man diesen nicht einfach bestimmen kann.