OsmLaneVisualizer

Ob ein Schild neben oder über der Fahrbahn hängt, ob es aus einem Stück oder mehreren separaten Teilen besteht, sollte für unser Tagging von destination:* keine Rolle spielen. Man könnte versuchen, die Art des Wegweisers über die Nummer des jeweiligen Verkehrszeichens zu erfassen, wenn man auf solche Informationen Wert legt.
Ob man einen Vorwegweiser wie [4] in destination übernimmt, bleibt wohl jedem Mapper selbst überlassen. Die einzige Position, an der man diese Information anbringen kann sind in jedem Fall die Hauptspuren im Bereich der Verzögerungsspur.
Zu [5]: Das Ziel der Abfahrt darf natürlich nicht an der Autobahn selbst angebracht werden, das Ziel der Hauptspuren hingegen muss an der Autobahn selbst angebracht sein.

Ergänzung: “destination” muss, wie im Wiki steht am motorway_link angebracht werden. “destination:lanes” kann (und muss, sonst macht der Tag keinen Sinn) allerdings schon an der entsprechenden Spur der Autobahn getaggt werden.

Schön wäre es vielleicht schon - aber ich sehe da ein paar Probleme. Bei einem kurzen Stück Straße mit 5-10 Ways geht das sicherlich noch, aber bei einer langen Autobahn sind das einfach zu viele einzelne Karten die jedes Mal mitgeladen werden müssten. Die einzige Lösung wäre wohl, die Karten erst bei Klick auf ein Element zu laden, aber dann hat man schon wieder kaum einen Vorteil zu den jetztigen Links zu osm.org und den jeweiligen Wegen.

Als Ergänzung:

Das ist aber kein Problem von OSM oder vom Tool, sondern von der Beschilderung. Wenn ich nach “Breitengüßbach Mitte” wöllte, dann fände ich es derbst schnafte, wenn mich mein Navi oder meine OSM-Karte (oder die offenbar fehlende Beschilderung) nicht über Buxtehude führt. Ich glaub auch, dass das Wiki dahingehend etwas irreführend sein kann, weil es zu den jeweiligen Destination(lane)s ein entsprechendes Schild dazuliefert.
Nach meinem Mapping-gefühl ist eine Destination aber eine Destination. Und nein, mit der Argumentation kann man nicht an jede Strasse ein destination=roma dranschreiben, da das Schema - zumindest an Autobahnen sehr eindeutig ist. (Destination=langfristige(s) Ziel(e)+nächste Abfahrt(en))

Danke dass du das hochbringst. Ja, das Tool favorisiert zur Zeit massiv das destination:lanes-Tagging gegenüber dem in einfachen Fällen (wie in deinem Bsp.) sinnvollere destination-Tagging. Der Grund liegt darin dass destination auf Abbiegungen nicht sichtbar sind. Destination:lanes sind komplexer, müssen öfter wiederholt werden und haben zzt. schlechteren Toolsupport.

Das ist bisher so, aber das muss ja nicht so bleiben. Wenn ein Weg in Vorwärtsrichtung wegführt gibt es jetzt (wenn “Adjacent ways” gewählt ist) noch ein weiteres Schild:
http://osm.mueschelsoft.de/cgi-bin/render.pl?wayid=66325467&start=1&placement&adjacent&extendway
Ist aber noch in Arbeit und noch nicht ganz fertig.
Wir ihr seht, können die URIs jetzt auch handlicher sein…

Habe noch etwas gefunden, auf das ich noch keine Antwort habe: Brückennamen, die als bridge:name getaggt sind: https://www.openstreetmap.org/way/151913380

EDIT: Jetzt habe ich glatt die Frage vergessen: Was machen wir damit? In Ordnung so, oder auf name umtaggen?

Naja, die Strasse ist auf der Brücke, die Strasse heisst nicht “Dingens-brücke”, von daher ist das imho ok so.
Gibt natürlich auch Sachen, wo die Unterscheidung einfacher ist, bspw. wenn sich der Name der Strasse vom Namen der Brücke unterscheidet…

Gut, sehe ich nämlich auch so, desweiteren gibt es ja extra ein Proposal für bridge:name, was im englischen Wiki zur bridge auch aufgeführt ist, nur in der deutschen Übersetzung fehlts mal wieder. D.h. aber dann auch, dass ich die folgenden Brücken der Strecke umtaggen werde, z.B. https://www.openstreetmap.org/way/211110671

@mueschel: Könntest du dann bridge:name noch mit aufnehmen? Danke :slight_smile:

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.