Zitat von Henry Loenwind <[EMAIL PROTECTED]>: > Frederik Ramm wrote: >>> "zeichne eine grüne Linie 2,2 Pixel breit in 1,3 Pixel Abstand >>> rechts des Ways"? >> >> Das kommt drauf an, ob einem irgendein gescheites SVG einfaellt, das das >> erzeugt. Osmarender errechnet grundsaetzlich nur die Mittellinie des
Zumindestens auf http://svg.tutorial.aptico.de/start3.php?knr=11&kname=Painting&uknr=11.1&ukname=Eigenschaften%20von%20Fuellungen%20und%20Randlinien fand ich keine Möglichkeit, die Linie automagisch zu versetzen. Also muss man das wohl im Renderer organisieren: > Auf so tiefer Ebene wird das schwierig. Das Problem ist vielleicht noch > nicht mal so sehr die Linie, sondern die Kreuzungen. Und damit dann auch > die Stellen an der der Way unterbrochen ist. Wenn man hier nur den > einzelnen Way ansieht hat man Unterbrechungen und Überlappungen. > > Also muss man zuerst die Wege zusammensetzen, die die gleiche Linie > haben sollen. An Kreuzungen mit mehr als 2 Wegen mit der gleichen Linie > muss man sich überlegen wie das aussehen soll. Im Zweifelsfall wird die > Linie dann in die Kreuzungsmitte gezogen (und verschwindet so unter der > Straße). > > Auf freier Strecke muss man an jedem Node aus dem Winkel der beiden > Linien zu den nächsten Nodes eine Richtung für einen Hilfspunkt > berechnen, über den die Linie dann parallel zur eigentlich Strasse > liegt. An Sackgassenenden berechnet man disen Punkt entweder senkrecht > zu Straße, oder in 45° dazu und haut echten Node noch dazu > (Pfeilspitze). An Kreuzungen s.o., wobei die "Pfeilspitzenmethode" hier > auch recht gut aussehen würde. > > Die ganze Winkelberechnung könnte man in einen Prepocessor auslagern, > dann ließe sich der einmal geschriebene Code für mehrere Renderer > benutzen. 1-2 Stunden Arbeit, würde ich sagen, wenn ich auf meinem > Straßennamenpreprocessor aufbaue. Ich versuche mal laut zu denken, was mir gestern im Laufe des Tages zum Problem mit Radwegen, Gleiskörpern, Anliegerfahrbahnen etc. kam: Nehmen wir mal die Karlsruher Karlstraße: http://www.openstreetmap.org/?lat=49.00763&lon=8.39497&zoom=16&layers=B0FT Von der hat schon irgendwer Teile in eine Relation gepackt (10744, highway=street, name=Karlstraße) Ich versuche mich mal in ASCII-Art, um deren prinzipiellen Verlauf darzustellen: X=secondary-Fahrbahnen, R=resid., T=tram, S=Service, P=pedestr., C=cycleway, Y=primary Links die Nummern der Bereiche zum Zitieren 00 RRRRRRRRRRRRRRRR Stephanienstraße 01 X 01 X 02 RRRRRRRRXRRRRRRR Akademiestraße 03 S X 03 S X 04 SSX 05 X 06 TPTPTPTPTPTPTPTP Kaiserstraße 07 T XT 07 T T 07 T TX 08 T X 08 T X 09 SSSSSSTSX Stephanstraße 10 T X Stephanplatz, Ludwigsplatz 11 PPPPPPTPXPPPPPPP Waldstraße 12 C T X 12 C T X 13 RRRRRRRRRRRRRRRR Amalienstraße 14 X T X 15 X T X R Herrenstraße 15 RR X T X R Sophienstraße 16 X T X 17 X T X 18 YYYYYYYYYYYYYYYY Kriegsstraße 19 X T X 20 YYYYYYYYYYYYYYYY Kriegsstraße 21 X T X 21 X T X .... 22 X T X 22 XTX 23 X 23 T 23 X 23 T Bisher gehören wohl alle passenden X zur Relation, nicht aber die C oder S oder T. Würde man die auch noch reinpacken, also alles, was zu einem gemeinsamen Straßenraum gehört (Gleise, Hauptfahrbahnen, Anliegerfahrbahnen o.ä., Radwege, ggfs. Fußwege, ... Nicht aber bspw. das Gleisdreieck in 07) könnte man gemeinsam Rendern nach folgendem Rezept: Bestimme alle (ungefähren) Parallelitäten oder Abzweigungen in der Relation: 01: "keine parallele Strecke zu X" 03: "S: rechts parallel X Nr. ..." "X: links parallel S Nr. ..." oder da S vermutlich ein Way in 03 und 04 und X ein way in 03/04/05: "S: parallel zu X Nr. ..., endet in dieser" "X: Parallele S Nr. ... zweigt links ab an Knoten ..." Suche die Mitte: Suche die höchstrangigen Straßentypen pro Abschnitt: Wenn geradzahlig, dann sei die Mitte zwischen den innersten zwei. Wenn ungeradzahlig sei die Mitte die mittlerste höchstrangige Fahrbahn. Wenn eine Tram vorhanden, nehme diese als Mitte. Numeriere die Parallelen links und rechts durch. Dieser Prozess könnte stellenweise nicht klappen. In Abschnitt 05 ist X, über die ganze Straße betrachtet, eigentlich zunächst nicht in der Mitte. Der Gleiskörper könnte in Seitenlage liegen statt in der Mitte. In 12 ist X nur einseitig, das Gegenstück hat einen anderen "Rang": C. Man muss also Einfluss üben können, z.B. role=middle um den korrekten Weg in der Mitte zu definieren. role=parallel um bspw. etwas als nichtmittig zu definieren (bspw. eigener Gleiskörper in Seitenlage) role=track3 um einen way als 3. Parallele zur Mitte zu definieren (wenn bspw. abschnittsweise eine Parallele wegfällt: Bsp.: ein Radweg über ganzer Länge als Nr. 3, eine Hauptfahrbahn über ganzer Länge als Nr. 1 plus eine Anliegerfahrbahn als Nr. 2, die aber zwischen den Querstraßen Y und Z fehlt). role=left/right dort wo bspw. abschnittsweise nur eine einzelne Fahrbahn da ist und nichtmittig laufen soll. Wenn alles sortiert ist rendern: Wenn Mitte belegt (Gleiskörper bspw.): Mittlerer way ist Referenz für ganzen Straßenraum. Wenn Mitte leer (Straßenbegleitgrün in der Mitte) ist die zu berehcnende geometrische Mitte der beiden mittleren ways die Referenz für den ganzen Straßenraum. Wenn Referenzen ermittelt ggfs. Abschnitts-Übergänge ausgleichen. Dann: keine Rad-/Fußwege li/re daneben: Standardrand der Fahrbahnen zeichnen. Rad-/Fußweg daneben: Standardrand fällt weg, werden durch Fuß-/Radweg ersetzt. (bzw. "Strichbreite" des Randes könnte auch definieren: Fußweg vorhanden oder einseitg oder gar nicht. Irgendwann tauchte diese Frage mal auf...) Dann Einzelwege von innen nach außen nach oben zitiertem Muster berechnen mit den Zusatzregeln: Abstand Wegmitte dieses ways zum nächsten weiter inneren way würde zu Überlappung führen: Way nach außen versetzen, sonst nicht. Dadurch werden Fälle wie im Abschnitt 15-17 bei adäquatem Maßstab lagetreu weiter weg von der Mitte gerendert bei kleineren Maßstäben wird generalisiert und der Schwenk fällt quasi weg. Bei der Abstandsfrage Standardrand ja/nein berücksichtigen. Wenn Rand beidseitig gleich: wie bisher breiten Weg unterlegen. Wenn nicht: einseitigen Hilfs-way berechnen und unterlegen. Dann Ränder-ways und hilfs-ways als SVG raus, dann Fuß- und Radwege, die ja ggfs. die Ränder ersetzen, dann Fahrbahnen. Gleise vor Fahrbahn, weil sie könnten auch den Standardrand ersetzen... Die Relation sollte noch ein type="irgendwas das sagt Straßenraum gemeinsam rendern" haben, damit der Renderer sie erkennt (und auch alle enthaltenen Elemente später nicht noch mal rendert). Sie kann, muss aber nicht, gleichzeitig eine "Straßenname-Relation" sein, die alle Elemente mit gleichem Straßennamen zusammenfasst. Es wurden ja schon Fälle genannt, wo das auseinander fallen kann. Knifflig werden sicher Kreuzungen, insbesondere wenn eine andere Straßenraum-Relation kreuzt... Weil dann sind ggfs. Radwegenden etc. anders zu positionieren. Evtl. muss man den obigen Prozess unterteilen: Zuerst Schritt A in allen Relationen, dann untereinander ausgleichen, dann Schritt B, dann abgleichen, ... Irgendwann die Ways außerhalb von Relationen ggfs. an der Kreuzung teilen und die Endpunkte passend zum Ergebnis der Relation "umpositionieren". Analog könnte man auch untersuchen, welche anderen ways zwar nicht direkt Kontakt zur Relation haben, aber im überzeichneten Bereich liegen (das Sackgassenproblem, dass hier schon mal erwähnt wurde), um deren Knoten unzupositionieren. Das ganze könnte man ggfs. erweitern zu "gemeinsamen Talräumen", damit in engen Tälern nicht Straße, Fluss und Bahn sich nicht überlappen. Soweit mal mein laut gedachter Denkanstoß. Mögen nun die Renderer-Experten prüfen, ob das überhaupt so umzusetzen geht und wenn ja, in wie viel Jahren... ;-) Gruß Mück _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
