Ich kann mir keinen Fall vorstellen, wo ein kategorisches bicycle=no allein aufgrund eine getrennt laufenden Radwegs gerechtfertigt wäre. Entweder steht ein explizites (Z254) oder implizites (z. B. Z275 oder Z331-1) Verbotsschild an der Straße oder die Benutzung der Straße ist unter Umständen auch immer für Radfahrer erlaubt.
Lustig wird das Routing auch, wenn der Bürgersteigmapper vergisst den Weg mit den einmündenden Querstraßen zu verbinden.
Wie hier in Dortmund-Wickede. Diese konkrete Stelle habe ich bereits korrigiert, aber da dürften noch ne Menge Fehler sein.
Genau. bicycle=no bitte nur bei “echtem Verbot” (Z254) mappen.
Mindestgeschwindigkeit ist ja interessant. Wenn ich als Radler die 30 schaffe darf ich dort also fahren oder wie… 
Für benutzungspflichtige Radwege hieße das passende Fahrbahngegenstück bicycle=use_sidepath.
Die Unterscheide sind durchaus relevant.
- für Fahrer spezieller Fahrräder nach VwV-StVO
- für das Einordnen zum Linksabbiegen
— wenn mal wieder vergessen wurde, den Radweg an die (Straßen-/Waldweg-)Einmündung auf der anderen Seite anzubinden
— generell seit einer der letzten StVO-Änderungen
… und wer nicht über eine solche abbiegt, eben nicht = Wahlfreiheit der Form des Linksabbiegens im Unterschied zur älteren Formulierung, die schon bei Vorhandensein einer Führung diese verpflichtend machte …
- bei Unbenutzbarkeit des Radweges etc.
Bei Fahrrädern wird meines Wissens von einer bauartbedingten Höchstgeschwindigkeit von 25 km/h ausgegangen. Aber eine eindeutige gesetzliche Regelung scheint es nicht zu geben. Sowieso ist die Gesetzeslage für Mindestgeschwindigkeit dünn.
Ich kapere mal diesen Thread, weil er einigermaßen zum Thema passt.
Hier im Nordwesten findet anscheinend ein kleiner Edit-War statt. Mittlerweile werden die Argumente schon als note=* an die Ways geheftet (z.B. https://www.openstreetmap.org/way/263195497/history bzw. https://www.openstreetmap.org/changeset/50613422)). So richtig zielführend ist das nicht…
Wer hat Lust zu vermitteln?
Und weiter geht der Edit-War.
Hmm. Ich verstehe schon die Intention, straßenbegleitende Radwege mit Straßennamen zu versehen, es macht alles aber auch sehr unübersichtlich. Von daher bekommen die Radwege von mir keine Straßennamen. Habe also nicht wirklich ne Idee, wie da ein Kompromiss aussehen sollte.
Ich verstehe ebenfalls, was das soll, nämlich dass der Router auch für Radfahrer Straßennamen ansagen kann, selbst wenn der Radweg straßenbegleitend verläuft. Aber ich kann mich für diese Lösung mit einem separaten name-Tag ebenfalls nicht erwärmen. Ich ziehe mal den Vergleich zu innerörtlichen Fußwegen, wo die als separater highway=footway bzw. highway=path neben der Straße gemappt sind: Dort wird auch der Straßenname nicht gedoppelt. Für die Ansage mag der Name schön sein, für die Übersicht auf der Karte ist es nicht zuträglich.
Als mögliche Kompromissidee: Ich frage mich, ob man die Relation:associatedStreet für solche Fälle aufbohren könnte, indem man dort neben den Rollen ‘street’ und ‘house’ noch eine weitere Rolle für straßenbegleitende Wege vorsieht. Damit wäre eine Zuordnung solcher Wege zum entsprechenden Straßennamen möglich, ohne dass er am Weg selbst stehen muss. Netter Nebeneffekt: Die “grandiose” Access-Angabe “use_sidepath” wäre damit deutlich besser handhabbar, weil klar ist, welcher straßenbegleitende Weg gemeint sein soll. Und sie wäre vor allem auch überprüfbar, inwieweit ein solcher Weg überhaupt gemappt ist.
Ich werf mal cycleway=sidepath in die Runde. Das könnte ein Renderer verwenden, um Radwege neben Straßen als solche zu erkennen und an diesen Wegen die Anzeige zu unterdrücken.
Davon halte ich nicht viel. Das sind wieder mal implizit eingeführte Logiken, bei denen ohnehin kaum noch jemand einen Überblick hat.
Vor allem ist der Standardfall dann genau das, was man vermeiden wollte: Ein Renderer, der den Umstand nicht kennt, dass er bei cycleway=sidepath den Namen wiederum nicht anzeigen soll, wird also standardmäßig den Namen zeigen. Ein Benutzer, der beim Taggen nicht darauf achtet, dass er bei straßenbegleitenden Radwegen cycleway=sidepath setzen muss, damit ein vorhandener Name nicht erscheint, wird ebenfalls dafür sorgen, dass der ungünstige Fall eintritt.
Ein zusätzliches Feature sollte im Regelfall zusätzlichen Tagging-Aufwand und zusätzlichen Auswerteaufwand machen. Es sollte nicht der Standardfall sein, der dann wiederum mit zusätzlichem Tagging- und Auswerteaufwand eingeschränkt werden muss. Denn das ist fehleranfällig auf beiden Seiten.
Hallo,
praktisch ist es so in Deutschland, dass an den allermeisten als separate Ways erfassten straßenparallelen Fuß-/Radwegen kein Name erfasst ist. Jetzt plötzlich einen Namen zu erfassen, ist ein aussichtsloses Verfangen.
Je mehr Objekte den Straßennamen tragen, desto fehleranfälliger sind Straßenumbenennungen.
Viele Grüße
Michael
Ist die Frage, ob Radfahrer das wollen? Ich persönlich schalte genau diese Funktion der Straßennamenansage aus, weil bis ich das Straßenschild entdecke, bin ich durch. Die visuelle Kontrolle ist verlässlicher, schneller und sicherer.
Eine Argumentation im Sinne des Beamten-Dreisatzes wird die Beteiligten wohl nicht unbedingt überzeugen…
Das ist natürlich schlecht zu verallgemeinern. Es gibt eventuell auch einige Leute, die nur mit Ansagen fahren oder die über eine entsprechende Ansage froh sind, wenn das Display wegen der Sonne nicht erkennbar ist. Das ist dann eher ein sinnvolle Option für den Router, ob solche Straßenansagen erfolgen sollen oder nicht. Die Daten sollten da neutral sein.
Ich wäre wirklich stark dafür zu prüfen, ob wir irgendwie eine datenmäßige Zuordnung von straßenbegleitenden Wegen zu der entsprechenden Straße hinbekommen können. Damit löst sich dieses Problem auf triviale Weise, ohne dass es spezielle Name-Tags an diesen straßenbegleitenden Wegen braucht. Und vor allem bietet das auch noch eine ganze Menge anderer Möglichkeiten. Dort fehlt momentan nämlich eine sinnvolle Datenverknüpfung.
chris66 hat die Street-Relation ja schon erwähnt. Das ist tatsächlich die sauberste Lösung, da es Bauwerk und Bedeutung trennt. Denn es ist ja strenggenommen nicht so, dass das flache Ding aus Asphalt plus Unterbau „Wilhelmstraße“ heißt, sondern dessen abstrakte Bedeutung als Verkehrsweg heißt so. Und zu diesem Verkehrsweg gehören alle begleitenden Fuß- und Radwege, Kreuzungen, Ampeln, Alleebäume, Wegweiser. Eine Relation würde Renderern das Benamsen deutlich erleichtern und hätte auch den Zweck, alle begleitenden Wege mit demselben Namen zu versehen, ohne dafür ein separates name-Tag zu vergeben (denn das steht dann alles nur noch an der Verkehrsweg-Relation, die Straße selbst hat nur noch ihre physischen Eigenschaften wie width und surface getaggt). Dann fühlen sich Renderer auch nicht mehr dazu veranlasst, nach jeder Way-Aufteilung ein neues Schild mit der ref in die Karte zu batschen, weil alle einzelnen Ways in der Relation sind. Hach, wäre das himmlisch.
Aber das braucht viel Umbau bei Editoren, bevor es einsteigerfreundlich ist, denn die Verwaltung dieser Relationen müsste größtenteils automatisch-transparent ablaufen; du kannst keinem Anfänger, der seine erste Straße in ein Wohngebiet zeichnet, erstmal verklickern, dass er dafür jetzt außerdem noch eine Relation anlegen muss, dass der Name an diese gehört und nicht an den way, und was für Regeln sonst dafür gelten, und was eine Relation überhaupt ist.
–ks
Interessant. Es wäre ja nicht unbedingt schwierig, das bekannter zu machen, indem man mal entsprechende deutschsprachige Wiki-Einträge anlegt. Ich habe allerdings Bauchschmerzen wegen der Parallelstruktur zu Relation:associatedStreet. Wir haben praktisch zwei Relation für fast den gleichen Sachverhalt. Das verspricht eigentlich nur unsinniges Chaos, was später kaum oder nur unter viel Aufwand wieder zu vereinheitlichen ist. Bezüglich der Verbreitung ist associatedStreet auch deutlich stärker repräsentiert.
Das würde ich jetzt mal nicht unbedingt als Show-Stopper sehen. Es würde doch ohnehin eine sehr lange Übergangsphase geben, weil auch die Renderer oft recht träge bezüglich der Übernahme neuer Features sind. Die Namen direkt an der Straße würden also auf recht lange Sicht nicht verschwinden, sondern es würde halt auf eine Redundanzsituation hinauslaufen, dass sowohl an der Straße als auch an der Relation der Name stehen müsste. Umgekehrt bleibt die Unterstützung der Renderer für Straßennamen direkt an der Straße, sofern diese Straße nicht Mitglied einer entsprechenden Relation ist, vermutlich auch noch recht lange erhalten. Das Einsteiger-Problem wäre also nicht unbedingt dringend. Zumal sich das auch recht einfach auswerten lässt, wo Straßen ohne Relationsmitgliedschaft sind, so dass dann auch ein erfahrener Nutzer dort leicht ergänzen könnte…
Das ist aber beispielsweise schon wieder ein bisher nicht vernünftig geregeltes Problem bei diesen Relationen. Denn ein “ref” kann wiederum auch nur auf einem Teil der Straße gelten. Braucht es für diese Straße dann zwei Relationen - einmal mit und einmal ohne ref für die entsprechenden Teile? Unangenehm, insbesondere wenn dann auch wieder straßenbegleitende Wege hinzukommen, die dann auch entsprechend aufgeteilt werden müssen. Bisher auf jeden Fall nirgends verbindlich geregelt…
Bundesstraßen und Autobahnen haben ja idR schon ihre “ref”-Relationen, vermutlich auch zunehmend niederklassigere Straßen?
Bei der Frage, wie man was in Relationen packt, sollte man auch Fälle betrachten, wo der Straßenzug inzwischen bautechnisch eindeutig geradeaus läuft, der Straßenname aber aus historischen Gründen “abbiegt” wie in KA-Durlach die Badener und Grötzinger Str, oder Auer Straße 2x, da bräuchte man wohl separate Relationen, eine Straßennamenstraltion, eine Straßenteilerelation …
Interessant fand ich damals auch die Straßenzuordnungen und Hausnumerierungen in Teilen Heusenstamms
Ich gehöre zu den Leuten, die nach Ansage fahren. Bloß wenn die Ansagen unklar sind, dann ist Display besser als Straßennamen aus oben genannten Gründen.
Simples Beispiel, wenn ich mich nach links einordnen muss, bis ich das Straßenschild lesen kann, müsste ich mich schon eingeordnet haben.
Klingt eigentlich ganz vernünftig. Das würde das ref-Problem komplett draußen halten, wenn man ref in Zukunft primär als selbstständige “Routenrelation” ansieht.
Straßenzüge sind in meinen Augen wenig relevant. Deren Abgrenzung wäre doch stets recht willkürlich. Was würde man außerdem konkret mit einer separaten Straßenteilerelation gewinnen?
“Interessant” trifft es ganz gut. Ist es dort wirklich so, dass es die Hausnummern auch noch doppelt gibt, z. B.: Konrad-Adenauer-Straße 1 und nochmals Konrad-Adenauer-Straße 1. Ich würde mal behaupten, da ist etwas faul und die Abzweige östlich der Kurt-Schumacher-Straße gehören zu dieser und nicht zur Konrad-Adenauer-Straße.