Problem mit separat eingetragenen Fahrradwegen

Graf Westerholt wrote:

Beim Fahrradfahren mit OsmAnd
...
ich höre dann nur die Sprachanweisungen über ein Bluetooth-Ohrstecker.
...
Ich finde es daher nicht zielführend, jeden straßenbegleitenden Rad- oder Fußweg extra einzutragen, es führt nur zu Irritationen bei Navigieren.

Es gibt auch andere Anwendungsfälle, die diese Daten benötigen. Wenn dich die straßenbegleitenden Wege beim Navigieren mit OsmAnd stören, wende dich an die dortigen Entwickler.

Edit: Typo

Entscheidend ist die bauliche Trennung. Ist diese vorhanden, kannst du nicht an jeder Stelle zwischen Fahrbahn und Radweg wechseln.

Graf Westerholt wrote:

Ich finde es daher nicht zielführend, jeden straßenbegleitenden Rad- oder Fußweg extra einzutragen, es führt nur zu Irritationen bei Navigieren.

Oft sind sie unnötig, da hast du Recht, in vielen Fällen sind sie aber wirklich so stark baulich getrennt, dass es da analog zum dual carriage way schon Sinn macht, sie separat einzuzeichnen.

Das Problem mit den falschen Abbiegeansagen tritt aber nicht nur bei Radwegen auf. Das kommt auch bei Straßen generell bei etwas komplizierteren Kreuzungen oder Kurven vor. Abhilfe schafft da vermutlich nur das Einführen eines Typs Realation, der klar macht, welche Weg(teil)e zusammengehören und was ein Abbiegevorgang ist. Das wird vermutlich schnell komplex und unübersichtlich.

TZorn wrote:

Abhilfe schafft da vermutlich nur das Einführen eines Typs Realation, der klar macht, welche Weg(teil)e zusammengehören und was ein Abbiegevorgang ist.

… sowie der Gebrauch von placement=transition an Way-Abschnitten, die nur der Anbindung dienen und keinen physischen Verlauf darstellen. Daraus könnten auch Router schließen, dass dort keine 45°-Abzweigung ist.

--ks

Graf Westerholt wrote:

Für Navis ist der Unterschied nicht zu erkennen.

Ja, das ist ein altbekannter Nachteil des Separatmappings.

Graf Westerholt wrote:

Beim Fahrradfahren mit OsmAnd leitet mich OsmAnd manchmal falsch, weil es sagt, dass ich abbiegen soll und ich in eine Straße abbiege, obwohl ich nur auf den straßenbegleitenden Fahrradweg fahren soll, welcher als eigener Weg in OSM eingetragen wurde

Ich nutze OsmAnd mit brouter und vermisse eine Ansage, wenn ich mit dem Rad von der Straße auf den (baulich getrennten) Radweg wechseln soll ! Das ist aber ein Problem von OsmAnd und muß dort gelöst werden.

Grüße aus Oberschwaben
Peter

kreuzschnabel wrote:

… sowie der Gebrauch von placement=transition an Way-Abschnitten, die nur der Anbindung dienen und keinen physischen Verlauf darstellen.

Hilft aber auch nur in den ersten beiden Fällen, aber nicht bei der Querstraße Q ...

␣␣␣␣␣␣␣␣␣␣␣␣␣Q
RRRRRRRRRRRRRRRRRRRRRRRRR
Q
SSSSSSSSSSSSSSSSSSSSSSSSS
E

... wenn man von der Einmündung E auf den Radweg R der Straße S will, da heißt es dann "rechts abbiegen in die Q" und stimmt dann ja auch, wenn direktemang folgt "linksabbiegen auf den R"

Ich sehe das auch als ein Problem an, dass durch die Navi-Software gelöst werden muss. Die OSM-Datenbank ist nicht speziell auf die Navigationsfunktion zugeschnitten. Und an sich macht es gerade im Umfeld von Kreuzungen Sinn, dass ich als Radfahrer über die teilweise komplett anders geführten Radwege durch den Kreuzungsbereich geführt werde und nicht einfach über die Autospur. Entsprechende Hinweise wie von Muek geschrieben muss dann halt die Software leisten.
Für mich ist dies ein Beispiel dafür, dass Navigeräte in der Praxis weiterhin ihre Berechtigung behalten werden: Fahrrad-Navi am Lenker (mit Kartenansicht) und Handy in der Tasche. Mulitfunktionalität hat halt auch seine Nachteile, wie eben das Akkuproblem, wenn man mit dem Smartphone navigiert.

Galbinus wrote:

Mulitfunktionalität hat halt auch seine Nachteile, wie eben das Akkuproblem, wenn man mit dem Smartphone navigiert.

Kann man leicht lösen, wenn man das Handy über einen Ladecontroler an den Dynamo anschließt oder eine entspr. Powerbank benutzt.

Galbinus wrote:

Ich sehe das auch als ein Problem an, dass durch die Navi-Software gelöst werden muss.

Das Problem sehe ich durchaus eher bei unseren Daten, oder allgemeiner beim fehlenden Bewusstsein für die Wichtigkeit von maschinenlesbaren semantischen Beziehungen.

Bei vielen Diskussionen in letzter Zeit (Getrenntmapping von Gehsteigen und Radwegen, Parkplatzflächen anstatt parking_lane etc.) merkt man sehr, dass separate Elemente von vielen intuitiv als "genauer" wahrgenommen werden. Aber das ist eben nur die halbe Wahrheit. Die Geometrie der Elemente ist genauer, aber die Zusammengehörigkeit zwischen den Elementen und andere semantische Information, die man beim Mappen über Tags an einem gemeinsamen Way immer hatte, geht verloren.

Nun ist es natürlich sehr motivierend, die eigene Arbeit in der Karte zu sehen, und dort wird man für die genauere Geometrie direkt mit sichtbaren Ergebnissen belohnt. Die Folgen der verlorenen Semantik sind dagegen zunächst einmal unsichtbar und wirken generell eher abstrakt. Da OSM aber eine für Maschinen verständliche Datenbank sein will, hoffe ich dennoch, dass sich längerfristig Lösungen durchsetzen, bei denen genaue Geometrie und klare Semantik Hand in Hand gehen. Das derzeitige Getrenntmapping, ohne eine Lösung zu haben, um weiterhin die semantischen Zusammenhänge ausdrücken zu können, finde ich voreilig.

@Tordanik, danke, sehr schön Ausgedrückt 🙂

Grüße von Lutz

Damit wird aber Eindruck erweckt, die Maschinenlesbarkeit sei wichtiger als ein menschenlesbares Kartenbild. Dem möchte ich widersprechen. Erstens werden ja auch immer mehr für das Auge gedachte Karten aus den OSM-Daten erstellt, zweitens ist die Maschinenlesbarkeit ja durchaus gegeben, nur die Umsetzung in sprachliche Navigationsanweisungen ist etwas schwierig.
Als Konsequenz deswegen nun auf das seperate mappen von neben einer Straße baulich getrennt herführende Fuß- oder Radwege zu verzichten, wäre meiner Meinung nach wenig zielführend.

Ich finde es nicht hilfreich, die verschiedenen Anwendungen der Daten gegeneinander auszuspielen. Ich möchte aber kurz daran erinnern, daß OSM gegründet wurde, um Daten für den Bau einer routing-engine zu bekommen.

Es scheint sich noch niemand öffentlich Gedanken gemacht zu haben, wie man mikromapping und routing unter einen Hut bekommt. Vermutlich weil jeder ahnt, daß dabei ein Drittes auf der Strecke bleibt: Einfachheit.

Baßtölpel

SammysHP wrote:

Entscheidend ist die bauliche Trennung. Ist diese vorhanden, kannst du nicht an jeder Stelle zwischen Fahrbahn und Radweg wechseln.

Ist das überhaupt relevant? Welches Navi wechselt dann einfach mitten auf der Straße die Seite, oder zwischen Fahrban und Radweg? OsmAnd tut das nicht. Wenn Navis sowieso generell nicht mitten auf der Straße die Seite wechselt, sondern an Kreuzungen, Einmündungen, an denen es auch in der Realität geht, ist das separate Eintragen der Fahrradwege überflüssig.

Ich kenne genug Situation, in denen von den straßenbegleitenden Radweg mehr Wege abgehen als von der Straße, ein Linksabbiegen aber nur über Umweg oder Nutzung der Fahrbahn möglich ist. Außerdem verlaufen Radweg oftmals nicht parallel zur Straße.

Graf Westerholt wrote:

.Wenn Navis sowieso generell nicht mitten auf der Straße die Seite wechselt, sondern an Kreuzungen, Einmündungen, an denen es auch in der Realität geht, ist das separate Eintragen der Fahrradwege überflüssig.

Wir mappen die Daten wie sie in der Realität vorhanden sind. Und da kann ein Radweg neben einer 3-spurigen Straßen durchaus 8-10 m neben der (gemappten) Mittellinie der Straße liegen. Und vielleicht nutzen künftige (genauere) Navis eine Kamera, die erkennen, auf welcher "Spur" man sich befindet ...

Moin,

Graf Westerholt wrote:

.Wenn Navis sowieso generell nicht mitten auf der Straße die Seite wechselt, sondern an Kreuzungen, Einmündungen, an denen es auch in der Realität geht, ist das separate Eintragen der Fahrradwege überflüssig.

das ist eigentlich genau das Argument, das für getrennt gemappte Wege spricht. 😉

Grüße, Georg

Nein, denn genau dafür gibt es lanes.

Graf Westerholt wrote:

... Irritationen bei Navigieren. Bei Straßen ohne extra eingetragenen begleitenden Wegen hatte ich bis jetzt keine Probleme.

Das ist ein Problem der Anwendung damit gut umzugehen mit den Ungenauigkeiten des Gerätes usw.... man zeichnet ja schließlich nicht für eine Anwendung.. oder einem Renderer.

OSMand kann sehr wohl damit umgehen.... zumindest ein bisschen... . OSMand formuliert dann so Ansagen wie "leicht" links Abbiegen... (oder so ähnlich)

Dann gibt es noch Anwendungsfälle wie Rollstuhlfahrer-Routing.. wo es immer mehr notwendig machen das extra zu mappen.. mit Bordsteinhöhen usw. 🤔

Die Frage stellt sich, ob für das Navigieren allein das Gehör oder nicht auch das Auge gelten soll. Aber das ist eher ein generelles Problem der Anwender von diesen Anwendungen, denn sonst würden solche Geschichten "das Navi hat mich hierhin geführt" nicht existieren.

Zum Fahrradrouting bei getrennt laufendem Radweg, gibt es die Möglichkeit ein access-Tag "bicycle=no" (edit: was ich nur in absoluten Ausnahmefällen anwenden würde) an die Straße zu setzen, aber ob das bei allen Straßen korrekt ist, kann man nur vor Ort herausfinden. Ich war aber davon ausgegangen, dass die RoutingApps bei vorhandenem parallelem Radweg diesem gegenüber der Straße den Vorzug geben, von daher ist es, wie schon mehrfach ausgeführt, Sache der Anwendung.

Thoschi wrote:

Zum Fahrradrouting bei getrennt laufendem Radweg, gibt es die Möglichkeit ein access-Tag "bicycle=no" (edit: was ich nur in absoluten Ausnahmefällen anwenden würde) an die Straße zu setzen, aber ob das bei allen Straßen korrekt ist, kann man nur vor Ort herausfinden.

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.

TZorn wrote:

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.

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.... 😄

chris66 wrote:

Genau. bicycle=no bitte nur bei "echtem Verbot" (Z254) mappen.

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

Die vorgegebenen Maße für die lichte Breite beziehen sich auf ein einspuriges Fahrrad. Andere Fahrräder (vgl. Definition des Übereinkommens über den Straßenverkehr vom 8. November 1968, BGBl. 1977 II S. 809) wie mehrspurige Lastenfahrräder und Fahrräder mit Anhänger werden davon nicht erfaßt. Die Führer anderer Fahrräder sollen in der Regel dann, wenn die Benutzung des Radweges nach den Umständen des Einzelfalles unzumutbar ist, nicht beanstandet werden, wenn sie den Radweg nicht benutzen;

- 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

(2) Wer mit dem Fahrrad nach links abbiegen will, braucht sich nicht einzuordnen, wenn die Fahrbahn hinter der Kreuzung oder Einmündung vom rechten Fahrbahnrand aus überquert werden soll. Beim Überqueren ist der Fahrzeugverkehr aus beiden Richtungen zu beachten. Wer über eine Radverkehrsführung abbiegt, muss dieser im Kreuzungs- oder Einmündungsbereich folgen.

... 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.

chris66 wrote:

Mindestgeschwindigkeit ist ja interessant. Wenn ich als Radler die 30 schaffe darf ich dort also fahren oder wie.... 😄

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?

highflyer74 wrote:

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...

Und weiter geht der Edit-War.

highflyer74 wrote:

Wer hat Lust zu vermitteln?

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.

maxbe wrote:

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

Kontinentalverschieber wrote:

Ich verstehe ebenfalls, was das soll, nämlich dass der Router auch für Radfahrer Straßennamen ansagen kann,

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.

Nakaner wrote:

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.

Eine Argumentation im Sinne des Beamten-Dreisatzes wird die Beteiligten wohl nicht unbedingt überzeugen...

GUFSZ wrote:

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.

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.

Kontinentalverschieber wrote:

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.

Gibt's ja alles schon, wird nur kaum genutzt.

https://wiki.openstreetmap.org/wiki/Relation:street

Kontinentalverschieber wrote:

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.

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

chris66 wrote:

Gibt's ja alles schon, wird nur kaum genutzt.

https://wiki.openstreetmap.org/wiki/Relation:street

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.

kreuzschnabel wrote:

Aber das braucht viel Umbau bei Editoren, bevor es einsteigerfreundlich ist, denn die Verwaltung dieser Relationen müsste größtenteils automatisch-transparent ablaufen

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...

kreuzschnabel wrote:

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.

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

Kontinentalverschieber wrote:

GUFSZ wrote:

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.

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 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.

Mueck wrote:

Bundesstraßen und Autobahnen haben ja idR schon ihre "ref"-Relationen, vermutlich auch zunehmend niederklassigere Straßen?

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.

Mueck wrote:

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 ...

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?

Mueck wrote:

Interessant fand ich damals auch die Straßenzuordnungen und Hausnumerierungen in Teilen Heusenstamms

"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.

Tordanik wrote:

[hnt. Die Folgen der verlorenen Semantik sind dagegen zunächst einmal unsichtbar und wirken generell eher abstrakt. Da OSM aber eine für Maschinen verständliche Datenbank sein will, hoffe ich dennoch, dass sich längerfristig Lösungen durchsetzen, bei denen genaue Geometrie und klare Semantik Hand in Hand gehen. de ich voreilig.

+1