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.
Mal einen Vorschlag auf die Schnelle, möglicherweise ist er großer Mist.
Den Gegnern der Radwegbenamsung geht es darum, dass es nicht mehrere parallele highway-Objekte gleichen Namens in der Datenbank geben soll, wo real nur ein einziger, nach Verkehrsarten gegliederter Verkehrsweg vorhanden ist. Außerdem machen die zusätzlichen Namenseinträge das Rendering unnötig unübersichtlich (dafür sind sie ja nutzlos), aber für den Renderer mappen wir ja eh nicht.
Den Befürwortern geht es darum, dass der Router auch dann während der Wegführung die Anweisung „Nach 150 Metern rechts ab in die Wilhelmstraße“ sagen kann, wenn das Routing sich nicht auf dem residential, sondern auf dem straßenbegleitenden path/cycleway bewegt. Das ist ein nachvollziehbarer Wunsch.
Es geht also darum, den straßenbegleitenden Weg dem höheren Highway, den er begleitet, namenstechnisch zuzuordnen. Dann sind Datenbank und Rendering aufgeräumt, weil der Radweg keinen Extra-Namen hat, aber der Router kann, wenn er am Weg selbst kein name-Tag findet, an der zugeordneten Straße fündig werden.
Relationen wären dafür geeignet, aber wenn’s noch eine einfachere Lösung gäbe? Relationen sind fehlerträchtig und erhöhen den Lernaufwand bei Anfängern enorm.
Wie wäre es denn (offene Frage, womöglich ist es scheiße), dafür das gute alte „is_in“ wiederzubeleben? Taggingtechnisch hätte das nur zur Folge, dass anstelle name=Wilhelmstraße an den Radweg is_in=Wilhelmstraße getaggt wird. Mehr muss nicht sein. In die Editor-Vorlagen lässt sich das leicht einbauen. Der wegführende Router müsste dann andererseits nur dort, wo er kein name=* findet, auch noch nach is_in suchen. Sollte auch mit einer Codezeile zu machen sein – die damit referenzierte Straße braucht er gar nicht mehr, ihm reicht ja der Name aus dem is_in-Tag:
$name = tag_auslesen("name");
if ($name == "") { $name = tag_auslesen("is_in") }
Machbar oder Mist?
–ks
Machbar sicher, aber so eher nicht wünschenswert. Wenn es nur darum geht, irgendein name-Tag dranzuklatschen, welches die Renderer ignorieren, das aber ansonsten auswertbar ist, dann wäre eine Konstruktion wie “cycleway:name” o. ä. sicher brauchbarer und nachvollziehbarer.
Vor allem hat dieses is_in-Tag bereits Semantik. Da kommt dann vielleicht jemand auf die Idee, hinter der Straße dann auch noch den Ort, das Bundesland und den Staat aufzuzählen, um auf Nummer sicher zu gehen. Damit ist die Auswertbarkeit mal wieder eine volle Katastrophe.
Nebenbei bin ich wenig angetan, hier jetzt mit so einer Flickschusterei anzufangen. Das ist dann alles schwer wieder aus der Welt zu bekommen. Und eigentlich ist doch auch Konsens, dass es eine Form von Verknüpfung von straßenbegleitenden Wegen mit der Straße braucht…
Zur Info und besseren Übersicht:
Der von highflyer74 weiter oben beschriebene Konflikt ist jetzt auch in einem anderen Thread ein Thema.