OsmLaneVisualizer

Dann muss er aber auch tunnel:name auch noch aufnehmen…

*Und schon haben wir 4 Finger seiner Hand… :smiley: *

@mueschel: Willst du solche Änderungswünsche (bridge:name und tunnel:name) eigentlich überhaupt hier haben - hat dich Jojo4u überhaupt gefragt - oder willst du das als GitHub Issues?
Bzw. würde ich sogar gerne mal einen PULL-Request ausprobieren.

Hallo Harald,
deine Änderungen sind übernommen (wenn auch gleich noch ein bisschen angepasst).
Vorschläge könnt ihr natürlich gerne sowohl hier als auch auf github posten, da bin ich nicht wählerisch.

Zwei Monate sind rum und es sind noch einige neue Keys hinzugekommen: https://github.com/mueschel/OsmLaneVisualizer/blob/master/README.md#interpreted-tags
Ich hoffe, dass im Augenblick keine schwerwiegenden Darstellungsfehler drin sind. Welche wichtigen Keys seht ihr noch, die ich bis jetzt ignoriere?

Zwei aktuelle Beispiele:
Es gibt ein Proposal zu :start und :end, das sorgt z.B. für eine bessere Beschreibung bei placement=transition. Vorhandene und fehlende Standstreifen gibt es hier auch:
http://osm.mueschelsoft.de/lanes/render.pl?wayid=242255434&start=1&placement&adjacent&lanewidth&extendway

Und am Wiesbadener Hauptbahnhof läuft der Verkehr schön getrennt nach Fahrzeugart:
http://osm.mueschelsoft.de/lanes/render.pl?wayid=336547095&start=1&placement&adjacent&lanewidth&extendway

Sieht sehr reell aus. Bzw. genau der Scheissdreck, den sich irgendwelche kranken Verkehrsplaner ausdenken. Ich fahr kein Rad, aber genau so eine Scheisse (in kleinerem Maßstab) sehe ich jeden Tag, also habe ich absolut keinen Zweifel, dass es perfekt eingetragen und perfekt gerendert ist (Ausnahmsweise vollkommen ohne Ironie…)

Krasses Beispiel übrigens, wollte mich grad noch am Routing an der Kreuzung: https://www.openstreetmap.org/#map=19/50.07161/8.24552 aufziehen, das is so übel kompliziert und (imho) wunderschön und perfekt gemappt.

Klitzekleines aber imho vernachlässigbares Problem bei deiner Auswertung: die Verbotsschilder für Radfahrer auf den Spuren ausserhalb des “Radweges” (hier: https://www.openstreetmap.org/way/43017507 ) sind eigentlüch überflüssig, weil implizit.

P.s. Ok, auf SO einer 5-spurigen Strasse würde ich jetzt mitm Rad nich wirklich freiwillig auf einer der linken Spuren fahren wollen…

Ja und nein. Ich zeige die Schilder, weil an den Spuren eben ein explizites “no” steht. Ich würde es auch nicht so taggen, aber es ist halt da. Wenn man sich bei taginfo die benutzten Werte für z.B. bicycle:lanes anschaut, glaube ich auch dass da einige falsche sind, z.B. wenn das benutzen der Linksabbiegerspur die einzige Möglichkeit für Radfahrer ist nach links abzubiegen. Bei kleineren Straßen innerorts kommt sowas ja durchaus vor. In dem Fall besteht die Benutzungspflicht der Radspur nicht für Linksabbieger, weil die Spur eben nicht in die richtige Richtung führt.
Bei psv:lanes ist die Sache noch schlechter, weil eine Busspur keine Benutzungspflicht beinhaltet - und hier ist ein “no” dann ziemlich sicher überall falsch.

Imho ist das bicycle:lanes=no|no|no|no|designated|yes des obersten Wegs nicht korrekt. Ist Radfahrern das Linksabbiegen tatsächlich nicht erlaubt? Sie dürfen sich ja zum Abbiegen einordnen. Lt. Mapillary kann ich keine getrennte Führung für Radfahrer entdecken. Außerdem ist das no nur implizit, ich würde hier folgendes taggen: bicycle:lanes=yes|use_sidepath|use_sidepath|use_sidepath|designated|yes.

EDIT: :lanes vergessen.

Ich glaube ihr meint bicycle:lanes oder?

Das würde ich nicht machen. Zum Einen landet der Radfahrer von der linken Spur dann in der Mitte der abgehenden Straße, er müsste eigentlich die zweite Spur von links nehmen, die sich in eine Abbiegerspur und eine geradeaus spaltet. Noch gefährlicher… Zum anderen verstehe ich use_sidepath so, dass es auf einen zusätzlich gemappten cycleway hinweist und nicht bei Spuren auf einem gemeinsamen highway verwendet wird.

Wird http://wiki.openstreetmap.org/wiki/Proposed_features/transit schon unterstützt oder ist das geplant (ggf. Subset)?

Könntest du vielleicht eine horizontale Trennung einführen wenn onway sich ändert? Jetzt ergibt sich nie ein passender Übergang wenn sich ein OSM-Way in zwei onway aufsplittet.

Genaugenommen ist das eher ein Problem in den Daten: Am Ende des oneway stimmt das placement (entweder explizit angegeben oder automatisch bestimmt) nicht, der letzte Node liegt ja nicht in der Mitte der Fahrbahn.
Das ist eine Anwendung von placement:start / placement:end wie hier:
http://osm.mueschelsoft.de/cgi-bin/render.pl?wayid=336854656&start=1&placement&extendway
Man könnte natürlich auch eine spezielle Regel für solche Übergänge einführen, allerdings muss ich dafür Weg-Segment übergreifend arbeiten, was ich im Moment nicht tue (Jeder Way wird unabhängig von allen anderen dargestellt).

Nein, wird noch nicht unterstützt. Würde ich gerne, aber ist eine Menge Aufwand.
In einigen Fällen weiß ich nicht genau wie ich es darstellen soll, in anderen ist mein jetztiges Konzept der gezeichneten Objekte nicht flexibel genug. Die Berechnung, welche Spur wann um wieviel verschwenkt werden muss ist dann auch nicht mehr ganz so trivial. Deswegen wird z.Z. auch placement:start nur berücksichtigt, wenn die Spurbreite nicht gezeichnet wird.
Langfristig müsste ich weg von der Darstellung als HTML und hin zu SVG, aber das ist aufwändig.

Lange hat’s gedauert, aber nun ist sie drin. Einfach mit der Maus links über die Way-ID fahren.
http://osm.mueschelsoft.de/cgi-bin/render.pl?wayid=295077058&start=1&placement&adjacent
Ansonsten gab es in den letzten Tagen noch ein paar Detailverbesserungen, ich hoffe es sind keine großen neuen Bugs entstanden - falls doch, bitte Bescheid geben.