Interpolations-Tag für Kreise, Kurven ...

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.

efred wrote:

die meisten renderer interpolieren automatisch.

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?

efred wrote:

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.

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.

Dennis[B] wrote:

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

gruss

wambacher

Hallo,

Dennis[B] wrote:

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.

Gibt es schon und nennt sich Bezier-Kurven.
Bei Osmarender sieht es so aus:

http://wiki.openstreetmap.org/wiki/Osma … zierCurves

Schöne Grüße

PA94

PA94 wrote:

Gibt es schon und nennt sich Bezier-Kurven.
Bei Osmarender sieht es so aus:

http://wiki.openstreetmap.org/wiki/Osma … zierCurves

Ja, allerdings ist der Algorithmus nicht sonderlich intelligent. Wenn der Knotenabstand groß
ist kann das schonmal enorme Abweichungen geben.

Chris

Hallo,

chris66 wrote:

PA94 wrote:

Gibt es schon und nennt sich Bezier-Kurven.
Bei Osmarender sieht es so aus:

http://wiki.openstreetmap.org/wiki/Osma … zierCurves

Ja, allerdings ist der Algorithmus nicht sonderlich intelligent. Wenn der Knotenabstand groß
ist kann das schonmal enorme Abweichungen geben.

Du bist herzlich eingeladen diesen zu verbessern (ernsthaft, nicht böse gemeint!).

Schöne Grüße

PA94

wambacher wrote:

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.

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.

Eine ähnliche Diskussion gab es schon mal hier: http://forum.openstreetmap.org/viewtopic.php?id=6198
Dort hatte ich geschrieben:

Stattdessen könnte ein Tag für den Knoten die Information speichern, daß sich an diesem Knoten nicht zwei Strecken in einem stumpfen Winkel treffen, sondern daß dieser Punkt in Wirklichkeit auf einer durchgehenden Kurve liegt. Insofern ist es m.E. richtig, die Information dem Knoten zuzuordnen. Diese Information geht im Moment verloren / wird nicht erfaßt. Warum sollte man sie nicht speichern?

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.

Grüße,
Philipp

1248 wrote:

Damit wäre der Aufwand de Taggens wohl so gering wie möglich gehalten.

Jedem Knoten eien Tag zuordnen ist aber kein "geringer Aufwand".

Ein paar mehr Punkte erledigen das gleiche doch genau so gut.

Dennis[B wrote:

1248 wrote:

Damit wäre der Aufwand de Taggens wohl so gering wie möglich gehalten.

Jedem Knoten eien Tag zuordnen ist aber kein "geringer Aufwand".

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

Dennis[B wrote:

Ein paar mehr Punkte erledigen das gleiche doch genau so gut.

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.

Grüße,
Philipp

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.

Dennis[B] wrote:

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.

Das war eigentlich meine Idee.
Tag auf Weg(abschnitt) legen: kurve=ja

und der Renderer weiß, dass er dann nach interpolieren kann z.B. kubische Interpolation

Dennis[B] wrote:

Das ganze muss aber auch sauber bearbeitbar und leicht pflegbar sein. Das sehe ich verdammt kompliziert an, wenn man die Tags noch vererben will.

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.

Dennis[B] wrote:

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

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/E … e.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.

Viele Grüße,
Philipp

1248 wrote:

Dennis[B] wrote:

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.

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

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

mpeter89 wrote:

1248 wrote:

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

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.

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.

mpeter89 wrote:

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 mit der Angabe von Radien sehe ich auch als unpraktisch an.

Grüße,

Philipp

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.

schlauchboot wrote:

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

Die Tags sollen ja auch nur für Sondersituationen da sein (runde Gebäude, eckige Flüsse...). I.d.R. wird man sie nicht brauchen. Nur muß man sie einmal ordentlich definieren. Und niemand *muß* sie anwenden...

schlauchboot wrote:

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.

Na ja... Kurven, die nach Klothoiden gebaut sind, mag man auf Deutschlands Straßen finden. Aber auch bei Flüsse oder auf Straßen in Kenia? Und ist in Deutschland auch jede Kurve in einem Feldweg so gebaut? Sicher nicht...

Abgesehen davon ändert das nichts an der einfachen Tatsache, daß Punkte in OSM zwei unterschiedliche Dinge darstellen (Knicke vs. Punkte auf Kurven), die man nach dem Erfassen nicht mehr voneinander unterscheiden kann. Das ist ein unnötiger Informationsverlust. Warum sollte man nicht die MÖGLICHKEIT (niemand muß sie nutzen) schaffen, diesem Verlust entgegenzuwirken?

Grüße,
Philipp

PS: Das "Sorry boys" klingt etwas herablassend, oder?

1248 wrote:

Die Tags sollen ja auch nur für Sondersituationen da sein (runde Gebäude, eckige Flüsse...). I.d.R. wird man sie nicht brauchen. Nur muß man sie einmal ordentlich definieren. Und niemand *muß* sie anwenden...

Zu Gebaeuden hatte ich mich nicht geaeussert. In Bezug auf Gebaeude hat mich der Ansatz, diese durch Polygonzuege nachzeichnen zu muessen, schon oefter "geaergert". Die vorhandene Funktion "rechtwinklig machen" funktioniert bei mir z.B. oefter nicht -- sei es, weil das Gebaeude zu viele Ecken hat, oder weil eine Schraege oder Rundung darin ist. Etc. Es ist schwer, die Symmetrie, die Gebaeude typischerweise haben, beim Nachzeichnen mit den aktuellen Mitteln wiederzugeben.

In Bezug auf Gebaeude stelle ich mir einen ganz anderen Ansatz vor: den Einbau von Graphik-Primitiven, wie sie heute jedes Zeichen- und sonstiges Office-Programm unterstuetzt, in die Editoren. Der Editor wuerde also erlauben, Kreissegmente o.ae. zu zeichnen. Diese koennen ja dann vom Editor automatisch durch einen Polygonzug mit einer moeglichst kleinen Anzahl von Punkten symmetrisch abgebildet werden -- solange OSM selbst keine weiteren Graphik-Primitive unterstuetzt (vielleicht also fuer immer...). Der Editor koennte auch das Ausrichten von Objekten nach vorgegebenen Winkeln erlauben. Da Gebaeude typischerweise in Fluchten ausgerichtet sind, koennte man letztere damit leichter abbilden. Damit koennte das Zeichnen von Gebaeuden viel einfacher werden -- und das Ergebnis saehe besser aus... Eine Spline- (oder sonstige) Interpolation wird meiner Meinung nach gerade ein durch einen Polygonzug "approximiertes" Gebaeude wohl eher nicht besser aussehen lassen (bis auf architektonische Sonderfaelle).

1248 wrote:

Na ja... Kurven, die nach Klothoiden gebaut sind, mag man auf Deutschlands Straßen finden. Aber auch bei Flüsse oder auf Straßen in Kenia? Und ist in Deutschland auch jede Kurve in einem Feldweg so gebaut? Sicher nicht...

Ich wuerde Klothoiden nicht nur in DE erwarten. Aber wie schon am Beispiel der Gebaeude ersichtlich, wird man wahrscheinlich nicht jedes Darstellungsproblem in OSM durch ein einheitliches Verfahren sinnvoll verbessern koennen. Vielleicht braucht man drei Ansaetze:

• Graphik-Primitive im Editor, die der Editor automatisch in Polygonzuege uebersetzt, z.B. fuer Gebaeude
• Interpolation auf Basis von Klothoiden im Renderer fuer Verkehrswege (in bestimmten Laendern... ;-))
• Spline- oder Bezier-Interpolation im Renderer fuer bestimmte andere Linien

1248 wrote:

PS: Das "Sorry boys" klingt etwas herablassend, oder?

Findest Du? -- war jedenfalls nicht so gemeint.

Straßen mit Bögen und Klothoiden in OSM abzubilden halte ich für sehr fragwürdig.
Liegen glücklicherweise mal genügend unabhängige Tracks vor, wisst Ihr alle, wie schwer es ist, den vermutlich wirklicheitsgetreuen Verlauf zu erahnen. Hat man dagegen nur den eigenenTrack, kommt man ganz schnell ins fabulieren. Dann muß man sich noch überlegen, wo man die Hauptpunkte der Klothoiden, bzw. Kreise legt und hoffen, dass daraus eine wirklichkeitsnahe Abbildung entsteht. Auf jeden Fall entsteht nicht das Bild, nach dem die Straße gebaut wurde.
Alleine einen wirklich richtungsgenauen Übergang zwischen Gerade und Kurve zu konstruieren anhand von GPS-Daten, die maximal 5m genau sind, naja, ich kann mir auch anders in die Tasche lügen.
Denkt auch noch an die Anfänger, die mit ihren eingenen "tollen, genauen, neuen" Tracks mal eben einen der Hauptpunkte verschieben, und hier anschließend nachfragen, warum der Weg plötzlich so komisch dargestellt wird.
Ich schlage vor, weiterhin Kurven durch eine jeweils passable Anzahl von Punkten abzubilden, frei nach dem Motto:
2 Punkte bilden eine Gerade und unendlich viele eine Ellipse und der Kreis ist die Sonderform der Ellipse.
Die Wahrheit liegt mal wieder dazwischen...

Bei Gebäuden würde ich mir folgenden Ansatz wünschen:
Da man, bei öffentlich zugänglichen Gebäuden mit dem Zollstock, oder per Schrittmaß um die Gebäude gehen kann, wäre es denkbar alle Maße in einem (zusätzlichen) Editorfenster einzugeben, um den Umring zu konstruieren (einige konstruktive Hilfsmöglichkeiten eingeschlossen, sog. Graphik-Primitive). So bekäme man, mit etwas Aufwand, einen sehr schönen Gebäudeumriss.
Mit GPS erfasst man, abschattungsfrei, Gebäudeverlängerungen und konstruiert daraus Schnittpunkte.
Zum Schluß werden 2 identische Punkte ausgewählt (aus Gebäudekonstruckt und den GPS Schnittpunkten) und das extern konstruierte Gebäude wird über eine Maßstabstransformation eingepasst. Voila - wie die Profis.

Gruß
Noframe