Das Problem ligt aber vorallem beim Renderer, der aus den Spurinformationen nichts sinnvolles ableitet fürs Kartenbild. Bei
lanes:type:forward=highway\cycleway|footway
lanes:type:backward=highway\cycleway|footway
Könnte er ja eine blau-rote parallele Linie links und rechts zum highway zeichnen. Tut aber kaum einer und dann führt es dazu, dass alles separat eingetragen wird, weil sonst das Fußgänger-Routing Mist aussieht im Vergleich zu Google & co.
Ich nehme mal an, die gelben Knoten haben noch ein kerb=*.
Was meinst Du? In JOSM gibt unabhängige Vorlagen, Erweiterungen und Kartenstile.
Das große Problem sehe ich ja in den vielen Tags. Allein Spurtagging für Fahrbahnflächen + Radstreifen ist nicht ohne und jetzt das ganze auch noch für die Barrieren und Seitenflächen wie Parkplätze und Rad- + Fußwege.
Auch ist es eher möglich etwas zusammenzubauen als etwas auseinander zu klamüsern. Aber ich gebe Dir Recht und habe es auch schon selber geschrieben, dass getrenntes Mappen eigentlich nur mit area:highway=*-Flachen und landuse=highway plus möglichst allen Barrieren bis zum Bordstein wirklich gut funktioniert. Allerdings funktioniert es zusammen an einer Linie eben auch nicht wirklich.
Super, damit fördert die Verwaltung nur aggressives Verhalten gegenüber Radfahrenden, die hier legalerweise die Straße benutzen.
“Spurmapping” halte ich für missverständlich, das könnte auch *:lanes[:*]=* sein. Hier geht es ja um individuelles Fahrspurmapping. Das ist so weit ich mich erinnere schon vor zehn Jahren abgelehnt worden. Ein großes Problem dabei sind Spurwechsel. Finde heute noch verstreut Abfahrten, welche am Beginn der Abbiegespur abzweigen und als separate Linie eingetragen ist. 
Mmh, weshalb die vielen abgesenkten Bordsteine, sind das alles Zufahrten?
Selbst als eine Person, die gewöhnt daran ist mit dem Fahrrad aus Straßenbahnschienen und über Bächle zu springen, ist ein Bordstein und ein Bächle erst Mal eine Barriere. Ich würde mir wünschen, wenn mein Fahrradrouter mich spätestens 50m vorm Linksabbiegen auf die Straße lotst oder im Profil ohne Anhänger und Gepäck mir wenigstens mitteilt, dass ich springen sollte.
Von Personen mit Einschränkungen und Mobilen die schon bei ein paar Zentimeter Höhenunterschied Probleme bekommen reden wir hier ja gar nicht.
Von 5 halte ich nichts, solange da keine bauliche Trennung existiert. Eine Laterne oder ein Verkehrszeichen kann auch mittig im Weg platziert werden.
Gegen die Barrieren als eigene Objekte spricht nichts. Ich bin da dann bei Variante 3+2 (1 mit 2 Spuren (Fahrbahn) + 2 (je ein kombinierter Geh/Radweg links/rechts) + 2 (Barrier/Bordstein)
Wie ich oben geschrieben habe ist das korrekte Routing sehr situations- und in diesem Detail auch sehr von den eigenen Vorstellungen und Voraussetzungen abhängig. Ja, die Barrieren wären wichtig und die Flächen schön, ab gibt es denn einen Router der is_sidepath plus Untertags verwendet und mit use_sidepath sauber umgeht? Der könnte ja auch die ersten und letzten Paar Meter Luftlinie berechnen, wie es bei fehlenden Verbindungen z.B. zur Haustüre auch gemacht wird. Ob ich mich dann entscheide über Grünstreifen und Bordsteine zu springen oder mir selbst den geeigneten Übergang suche bleibt mir ja immer selbst überlassen. Andere wollen aber eben den Übergang mit genügend Breite und auf beiden Seiten zumindest abgesenkter Bordstein.
Das ist doch schon in parking:lane enthalten. Oder geht es Dir um ein eigenes Objekt für die Parkfläche?
Ja, an sich schon. Man könnte aber auch per Abbiege-Relation ausdrücken, dass bpsw. ein Fußgänger oder ein wheelchair nicht gerade aus gehen/rollen kann an der Kreuzung.
Ich meinte das grafische Turn-Lanes-Tagging Tool. Wo man ohne Kenntnisse des Schemas sich zusammen klickt, wie es vor Ort ist. Die müsste dann ein wenig erweitert werden 
Ich kann mir gut vorstellen, dass das komplexer ist als aktuell, keine Frage. Aber es ist eine lösbare Sache, die auf der einen Seite gutes Routing und auf der anderen Seite eine gute Kartendarstellung ermöglicht, ohne den Mappingaufwand extreme zu erhöhen.
Ich denke da sind deine Ansprüche zu hoch. Der Router soll dir einen guten und nutzbaren Weg von A nach B geben. Aber du musst schon noch selber auf die Straße schauen und die Situation einschätzen. Vorallem im Nahbereich. Oder soll der Router auch noch wissen, dass der abgesenkte Bordstein in 50m von einem haltenden Auto belegt ist (oder es eine tiefe Pfütze hat) und du besser schon 100m vorher auf die Straße wechselst
Wünschen würde ich mir sowas aus, aber realistisch ist es in meinen Augen nicht. Zumindest nicht aktuell.
Guter Tipp, mit dieser Erweiterung für JOSM konnte ich ein paar Sachen ins Reine bringen, die mir Osmose seit Längerem schon aufgehalst hatte - Lanes tagging ist ohne nämlich zum Haareraufen, aber so, das könnte zum Hobby werden 
Ich schließe mich da Hungerburg an, das würde ich nicht über lanes machen sondern als eigenen Weg. Grundsätzlich sollte das aber auch über lanes gehen, es braucht - wie du schon schriebst - nur eine Angabe, zwischen welchen Spuren man wechseln kann.
Das über ein alternatives Symbol zu ‘|’ zu machen finde ich spannend. Die Raute ‘#’ wäre da meines Erachtens noch besser geeignet als '', die sieht aus wie etwas Durchgestrichenes. Man braucht dann aber auch ein Symbol für “Spurwechsel erlaubt” denn der klassische Strich ‘|’ trägt keinerlei dieser Informationern in sich. Vielleicht ein ‘+’?
Ich musste kürzlich auch lernen, dass ‘type’ kein guter Schlüsselname ist, weil man aus ‘type’ nicht erkennen kann, wass für ein Wert dort erwartet wird. Statt ‘type’ müsste dort Stehen ‘main_user’ oder so ähnlich. Aber: Bisher haben wir die Widmung der Spuren über die access-Tags abgebildet, hier als Beispiel für eine zweispurige Fahrbahn mit Radstreifen und Benutzungspflicht in Geradeaus-Richtung. Das müsste doch reichen, oder?:
vehicle:forward=yes|yes|no
bicycle:forward=yes|no|designated
turn:lanes:forward=left|through|none
Hier könnte man nun z. B. das turn:lanes verwenden, um die Querungsmöglichkeiten zu eruieren, z.B.
turn:lanes:forward=left+through#none
Also durchgezogene Linie zwischen Radstreifen und Geradaus-Spur, gestrichelte zwischen Geradeaus- und Lonksabbiege-Spur.
Aber wenn du so etwas viorschlagen wilsst, solltest du eine neue Diskussion beginnen.
Hinweis: vor Kurzem hatten wir ein ähnliches Thema diskutiert. Dort ging es um den Übergang von Spuren beim, Wechsel einem way auf den nächsten.
Für das Beispielbild der Verkehrswende Berlin-Mapper mit den parallelen Rad- und Gewegen würde beim Zusammentaggen aber Folgendes reichen:
cycleway:kerb=yes
Wobei ich das als Standardwert ansehen würde, wenn kein anderers ‘kerb’ getaggt wurde.
Das ist beim Zusammen-Mappen doch datenmäßig problemlos möglich. Programmiere den Router so, dass er nur dort den Radweg verlässt, wo
am Weg ‘cycleway:kerb=no/lowered/flush/rolled’ oder ‘cycleway:kerb:height<=3cm’ getaggt wurde
eine Grundstückseinfahrt oder Straße von rechts kommt
am Knoten ‘highway=crossing’ mit dem Tag ‘kerb=no/lowered/flush/rolled’ oder ‘kerb:height<=3cm’ getaggt wurde
Routing ist nicht gleich Routing. Hier wird sich ein Mikro-Routing gewünscht. Auch für barrierefreies Routen für z. B. Rollstuhlfahrer oder eine genaue Abbildung in der Kartendarstellungen der Navigationsgeräte erscheint Mikro-Routing hilfreich.
Wer zügig mit dem Fahrrad oder gar Auto unterwegs ist, braucht dagegen Abstraktion, also Makro-Routing. Da kann man nicht alle 10m mit neuen Hinweisen überfordert werden.
Auch hier gibt es kein Gut und Böse. Mikro-Routing geht mit dem Getrennt-Mapping besser, das andere mit dem Zusammen-Mapping.
Und auch hier: Wenn man beim Getrennt-Mapping die ein-eindeutige Zuordnung zwischen Radweg/Gehsteig und Fahrbahn hinbekommen würde, so könnte man auch mit Getrennt-Mapping ein abstrakteres Routen machen. Der Router muss nur vorher die Eigenschaften der Radwege/Gehsteige an die Fahrbahnkante übertragen um dann die Radweg-/Gehweglinien auszublenden. Aber leider gibt für diese ein-eindeutige Zuordnung noch kein Datenmodell. Daher ist dafür bislang das Zusammen-Mappen die bessere Alternative.
Das klingt versöhnlich, nicht sicher ob ich dem uneingeschränkt zustimmen mag. Z.B. auf eine Straße mit Gehweg nur auf einer Seite:
Was hier Makro oder Mikro ist? Frei nach Henning: das sieht man dann, wenn man dort ist, oder nah dran genug.
Es geht hier ja um Radwege, und nicht um Gehwege; Aber selbst Leute mit vermindertem Sehvermögen, die man selten Radeln sieht, auch mit Lastenfahrrad nicht, die stimmen da wie dort zu, wozu auf die Straße wechseln, wenn es nicht sein muss, im Fall der straßenbegleitenden Gehwege, nicht einmal sein darf?
Nein, in typischen Makro-Routing kannst du nur an Kreuzungen oder anderweitig definierten Übergängen die Straßenseite kreuzen. Du würdest also min. eine Kreuzung eher auf die richtige Seite gelotst. Du bekommst aber auch keinen Stromschlag, wenn du es nicht machst. Nichts-desto-trotz sollte die Route “funktional” sein. Bspw. wenn eine Kreuzung vorher keine abgesenkte Bordsteinkante vorhanden ist, würdest du beim Rollstuhlrouting evtl. eine Kreuzung weiter geroutet und dann ein paar Meter auf der anderen Seite zurück. Es obliegt dann deiner Einschätzung vor Ort, die Straße auch schon eher zu überqueren, wenn du kannst. Auch hier gibts keinen Stromschlag vom Navi.
Ja, wobei ich hier kaum Vorteile sehe. Nicht ohne Grund setzten auch alle “autonomen” Fahrzeuge im Detail auf eigene Umgebungserfassung und nicht auf Kartendaten. Was hilft es dir im Micro-gemappten Datensatz, wenn die Rabauken gestern Bierflaschen zerkloppt haben und du mit dem Rollstuhl nicht mehr die Abgesenkte Bordsteinkante nutzen kannst. Dass du selber nachdenken musst, wirst du nie micro-gemappt bekommen.
Habe da jetzt nicht so wirklich über das perfekte Trennzeichen nachgedacht. Sinnvoll klingt:
| = Spurwechsel möglich
# = kein Spurwechsel
\ = Spurwechsel nur von rechts nach links möglich
/ = Spurwechsel nur von links nach rechts möglich
Wäre auf der einen Seite eine gute Idee,weil man weniger Neues definieren muss, auf der anderen Seite hättest du mit der Art die Möglichkeit auch spezielle Spuren zu klassifizieren. Sowas wie eine Standspur auf der Autobahn beispielsweise.
Achtung, damit definierst du dieses Zeichen um. Bisher stand es nur als Spur-Trenner ohne Aussage über das Spur-Wechseln. Mit diesem Vorschlag würde es aussagen, dass ein Spur-Wechsel möglich ist. Mit der Umdeutung weiß niemand mehr, ob die alte oder neue Bedeutung gemeint ist. So etwas sollte vermieden werden.
So war es beim Einführen von ‘surface=sett’. Seit dem weiß man bei ‘surface=cobblestone’ nicht mehr, ob da wirklich das runde Katzenkopfpflaster liegt oder doch gehauenes, ebeneres Pflaster.
Daher sollte ‘|’ für “Keine Angabe zu Spurwechsel” stehen. Für “Spurwechsel möglich” müsste ein anderes Symbol her. Ich dachte an ‘+’ oder besser ‘-’. Zu prüfen wäre, ob diese beiden Symbole nicht bereits für andere Taggings belegt sind, z. B. in conditional restrictions und ob diese Taggings an dieser Stelle in Frage kommen. Z.B. für eine Spur, die nur Samstag-Sonntag+Feiertags eine Abbiegespur ist.
Ich habe im Wiki kein OSM-Tagging für Standspuren gefunden. Dein Vorschlag würde dann an einer 2-spurigen Fahrbahn möglicherweise so aussehen:
lanes=2
emergency_stop=no|no|yes
Aber: Die lanes-Angaben in ‘emergency_stop’ bilden nur “Fahrspuren” ab, nicht den ruhenden Verkehr. Es müsste sich also eher an dem Tagging vom straßenbegleitenden Parken orientieren, wober das “parking” in meinen Ohren nicht passend ist, denn es ist eher ein Nothalt. Zu vermeiden wären Partplatzsymbole an Nothaltebuchten. Also eher
emergency_stop:lanes=right
Das wird jetz allerdings immermehr off topic. Du solltest einen neue Diskussion dazu starten. Hier geht es ja um Vor-/Nachteile für Zusammenmappen von Radwegen an der Straßenkante.
Sorry, hab gerade nicht viel Zeit, daher nur kurz ein wichtiger Hinweis
Oh, dass ist aber sehr rudimentär. Wo ist da die Unterstützung für Fahrradstreifen und Busspuren? Sowas wie access tags und change wären schon schön.
Habe es gerade zum ersten Mal ausprobiert und gleich einen Bug gefunden, da die Erweiterung lanes=* und lanes:backward/forward in einigen Situationen falsch berechnet.
Das ist es natürlich nicht gut, dass weder F1 auf den Tags zu den Wikiseiten führt noch sonst wo ein Link zum Taggingschema vorhanden ist. 
Edit: Zitat richtig gestellt.
Das ist ja eine Frage, wie man den Router programmiert. Will ich überall Queren/Wechseln wo es nicht ausdrücklich verboten wurde oder nur an ausgewiesenen Querungen? Das kann der Router selber entscheiden.
Auch das muss kein hartes “entwederoder” sein, man kann das direkte Queren mit Maluspunkten versehen, vielleicht sogar abhängig von der Anzahl der Spuren, vom Straßentyp und der Breite … Hier könnte man durchaus die Profile verwenden, der Eine mag es, der andere nicht. Das betrifft auch den Wunsch von skyper, beim Linksabbiegen vor einer Kreuzung auf die Straße zu wechseln oder lieber doch direkt an der Kreuzung indirekt links abzubiegen.
Genau, nur weil man es machen kann heißt das nicht, dass man es machen muss oder ob es überhaupt praktikabel ist.
Wir sollten unabhängig davon versuchen die Daten so zu erfassen, dass man damit so viel wie möglich anstellen kann. Allerdings besteht die Gefahr, dass wir es den Basic-Funktionen schwer machen (z. B. Routing für Normal-Radfahrer) um es Spezialanwendungen leichter zu machen (z. B. Barrierefreies Routen).
Daher plädiere ich dafür sich nicht auf Getrennt- oder Zusammenmappen festzulegen sondern das jeweilig passende Schema zu wählen, in Abhängigkeit davon, wie kompliziert das da draußen ist und wie detailliert gemappt wird.
Achso, Folgendes habe ich nicht verstanden:
Würde ich gerne, aber wozu genau braucht man die Flächen? Als logische Verknüpfung der Spuren im Seitenraum mit den Spuren der Fahrbahn? Ist das die gesuchte ein-eindeutige Verknüpfung zwischen den Linien im Seitenbereicht und Linen der Fahrbahn? Wie genau soll das funktionieren, insbesondere wenn die Linien über mehrere Flächen gehen?
Die fehlende Verknüpfung zwischen Fahrbahn-Linien und Seitenraum-Linien wurde als nachteil des Getrennt-Mapping ja bereits genannt.
Dass du das fragst Ich hab das hier aufgegriffen, oben #55:
In einem Vortrag beschreibt ein Radrouter Entwickler Ähnliches, gesucht, gefunden - https://www.cyclestreets.org/news/2019/09/22/sotm2019/ - nicht opencyclemap sondern cyclestreets. Die Sache ist ein wenig komplexer, aber generell seh ich das so, dass detaillierteres Mappen die Probleme vermehrt, anstatt sie zu verringern. Und der einzige Ausweg, wenn die “Schienen” einmal gelegt sind, der ist, noch mehr zu machen: Flächen definieren, wo es erlaubt ist, die Schienen zu verlassen. Nicht nur auf den ersten oder letzten 10 Metern.
Auf den letzten Metern ist das sicher bequem, aber mitten auf der Strecke kann so ein “Hupfer” in die Hose gehen. Da helfen nur die erwähnten Flächen. In vielen Fällen würde es auch reichen, nicht separat zu mappen, aber das ist scheints nicht wirklich in.
Ich hätte wohl schreiben sollen “Ein Makro-Router stellt mich einfach an der Straße ab, wo das Ziel am nächsten liegt”, und es bleibt mir überlassen, wie ich mich dann weiter zurechtfinde; ein Router also, der nur die Information hat, dass an der Straße auf einer Seite ein Radweg ist. Die rudimentäre Information über den Radweg ist trotzdem nicht umsonst, sie kann zB eine Route appetitlicher als eine andere machen.
Stimmt, es ging primär zu schauen, was man mit “Zusammen-Mappen” noch erreichen kann und was nicht.
Wenn man es zusammen fasst: Man kommt in speziellen Fällen nicht um ein getrennt mappen herum, aber ein Großteil der begleitenden Wege könnte in einen sinnvollen Näherung per Tag abgedeckt werden. Es fehlt aber hier komplett an Unterstützung der grafischen Auswerter und bedingt an Unterstützung der Mapper beim Eintragen. Es wird der Weg des geringsten Widerstandes genommen, was dann im getrennt-Mappen endet, weil es scheinbar einfach schön anzusehende Karten produziert und scheinbar besseres Routing.
ich habe mich hier mangels Zeit eine ganze Weile lang zurückgehalten, wollte aber anmerken, dass das Getrenntmapping nicht bedeutet, dass es unmöglich ist, daraus die Radwegeigenschaften auf die Straße zu übertragen, auch wenn sie dort nicht explizit gemappt sind. Vielmehr wird das dadurch viel aufwendiger, es ist aber grundsätzlich möglich (durch komplexe Datenbankabfragen). Andererseits ist es nicht möglich, fehlende Geometriedetails aus dem impliziten Mappen von straßenbegleitenden Wegen als tags auf einem geometrisch unabhängigen highway=“straße” irgendwo herzuleiten.
Weiterhin wollte ich fragen, was ihr von dem impliziten Mappen von Straßen an Radwegen haltet? Man könnte ja durchaus alternativ zum hier diskutierten Vorgehen auch nur den highway=cycleway mappen und die Straße daneben weglassen, dafür aber einen tag residential_highway=left oder so an den Radweg ergänzen, der die Straße repräsentiert. Dadurch könnte man noch bessere Fahrradkarten rendern, und würde nicht den Bezug der Straße zum Radweg verlieren. residential_highway:maxspeed=50, residential_highway:lanes=2, etc., man kann so im Prinzip alles abbilden, vor allem wenn die beiden Wege parallel verlaufen und man jederzeit vom Radweg auf die Straße wechseln kann.
+1
Machst Du das propsal? Ich stimme dafür!