Ich bin kürzlich in Düsseldorf über einige hundert straßenbegleitende Rad- und Fußwege gestolpert, die den Namen ihres jeweiligen Hauptweges tragen. Einschließlich der Überwege.
Das ist mir so bislang sonst noch nicht aufgefallen. Oder schon einmal in anderen Varianten (is_sidepath:of:name).
Ist das richtig, falsch, geduldet?
Ist (wie so vieles) umstritten. 
Persönlich nehme ich street:name statt name. Auswerter können dann entscheiden ob sie das nehmen wollen oder nicht.
Umstritten, wie @chris66 schon schrieb.
footway=sidewalk und/oder cycleway=sidepath am Rad-/Fußweg erlauben es ebenfalls ‘name’ zu ignorieren.
Und damit haben wir schon zwei diskutier(te/bare) Ansätze das “Problem” zu lösen, falls es einer Lösung bedarf.
Radwege und Fußwege haben idR. keine Namen. Manchmal wäre es aber schon praktisch. Ich beschäftige mich gerade mit Wanderwegen. Es wäre schon einfacher, sich in den Relationen zu orientieren, wenn es da öfters etwas wie Straßennamen gäbe.
Derzeit gibt es Fußweg, 2 nodes, dann Feldweg 6 nodes, Feldweg 8 nodes, Staße mit Namen und dann wieder Fußweg, 5 nodes…
Das Problem, das da dahinter steht, ist, dass man gerne die straßenbegleitenden Wege irgendwie der Straße zuordnen möchte. Dafür benötigt man, wenn man nicht anhand der Koordinaten suchen möchte (ist aufwendig und fehleranfällig), irgendeine Referenz. Mit dem Namen geht das einigermaßen gut und es entspricht dem, was wir in OSM auch an anderer Stelle nutzen (Hausnummern, gestückelte Straßen etc.). Ich bin trotzdem kein Fan davon, weil es halt gigantische Datenredundanz erzeugt.
Alternativ könnte man sowas mit einer Relation lösen. Das wäre datentechnisch die sauberste Lösung. Relationen haben aber den eklatanten Nachteil, dass sie sich (aus Mappersicht) wie Kit verhalten: Wo du Relationen ins Spiel bringst, ist alles zuzementiert, Änderungen werden immer schwieriger und sind irgendwann nicht mehr mit halbwegs vertretbarem Aufwand möglich. Das hat man jetzt schon bei den (Bus-)Routen und ähnlichem. Wenn man ganze Straßen (inklusive Häusern und Seitenwegen) so zusammenkitten würde, wäre es vorbei mit den Änderungen. (@Netzwolf hatte mal die Idee ins Spiel gebracht, dass man nicht von den Relationen die Elemente verlinkt, sondern von den Elementen die Relationen, das könnte das Dilemma vielleicht lösen. Ich hab’s aber bislang noch nicht durchdacht, welche Auswirkungen das wirklich haben würde.)
jo - so ähnlich sehe ich das auch. Fußwege mit Namen wären für das Randthema Wanderwegrelationen besser. Aber die Nachteile, die man sich damit woanders einhandeln würde…
Irgendjemand muß den Kram ja auch pflegen - und DAS sollte so einfach wie möglich sein!
Danach könnte jedes Element nur noch in einer einzigen Relation sein, das wäre die logische Konsequenz[1][2].
Was Du „Hauptweg“ nennst, ist die Fahrbahn. Und zusammen mit der Fahrbahn bilden die fahrbahnbegleitenden Wege dann die Straße. Und die hat einen Namen. Nicht die Fahrbahn, nicht die einzelnen Wege.
Ob man das so wie beschrieben modellieren will … wie die Vorredner schrieben: umstritten.
Es sei denn, man würde mit Semikolon-separierten Listen für Referenzen auf Relationen arbeiten. Aber jetzt mal Hand aufs Herz: ist das einfacher? ↩︎
Und anhand wovon will man die Relation verlinken? ID der Relation? Die kennt man ja nicht vor dem Erstellen. Ohne wirklichen Support vom Editor ist diese ganze Überlegung aber auch hinfällig 
Und mit gutem Editor-Support ist theoretisch auch mit der jetzigen Modellierung alles möglich ↩︎
Ich hatte das jetzt eher als zusätzliche Angabe bei den Elementen verstanden (würde eine Änderung der Datenstruktur notwendig machen), nicht als Tag. Bei den Relationen wird das ja derzeit auch nicht als Tag gespeichert. Als Tag ist definitiv doof.
Es entspräche vor allem dem Grundsatz “one feature - one OSM element”, wenn an einem Way nur seine physischen Merkmale stehen (Belag, Breite, Fahrstreifen, Beschränkungen) und die Straße, zu der dieser Way gehört und die ja real nur ein einziges Objekt ist, konsequent als Relation in den Daten wäre. Alle Metadaten der gesamten Straße wie name=* oder ref=* wären dann ausschließlich an der Relation getaggt. Elemente der Relation wären alle Fahrbahnen, fahrbahnbegleitenden Wege, Wegweiser, Einfahrten usw. Dann würde jede Suchfunktion in Kleckersdorf nur ein Objekt namens Goethestraße sehen und nicht wie jetzt Dutzende, deren Zusammengehörigkeit geraten werden muss.
Das ist nur leider alles andere als einsteigerfreundlich, und das ist der Spagat, den wir in OSM überall machen müssen (Einfachheit vs. Präzision des Datenmodells).
Ich stimme dir da im Wesentlichen zu, nur bei
würde ich einen Schritt weitergehen, und behaupten wollen, dass das auch für die Experten kaum noch machbar ist mit dem aktuellen Datenmodell (also mit Relationen).
Als die Relationen 2008(?) eingeführt wurden, dachte ich, dass das genial ist. Mit dem heutigen Wissen würde ich Relationen gerne wieder aus dem Datenmodell entfernen und durch etwas besseres ersetzen. Ich weiß nur noch nicht, was das wäre… 
Ich glaube, es ist eher Mapper-Sicht vs. Datenutzer-Sicht. Aber vielleicht kommt das auch aufs Gleiche raus.
(Ist das schon off-topic?)
Relationen werden leider viel zu häufig missbraucht. Sie sind eigentlich dafür da die Beziheung zwischen 2 (oder mehr) anderen OSM Objekten zu beschreiben.
Leider sind halt viele relationen nur “Sammelrelationen”. Alles Autobahn A2, “Alles Bundesstraße 64” - DAFÜR sind Relationen aber nicht gedacht.
Und IMHO sollte eine Relation immer die “ultima ratio” sein für die Dinge die wir anders wirklich nicht erschlagen bekommen. Es gab mal einen Talk auf einer SoTM in der raus kam das quasi alle relationen ausser multipolygon eher unsupported sind. Ein bisschen hat sich das mit turn restrictions geändert. Aber alles andere ist kaputt, und turn restrictions sind leider auch ein Quell des kaputten routings.
D.h. ich finde die variante mit “street:name” schick - Damit kann man wenn man möchte den link zur Ursprünglichen Straße (Eigentlich Fahrbahn) herstellen, aber das wird nicht prominent gerendert.
Wir haben uns da als OSM ja deshalb ein Beinchen gestellt weil wir angefangen haben Straßenbegleitende Rad und Fußwege separat zu mappen.
Vielleicht wird das wieder besser wenn wir mit highway Flächen anfangen. Dann könnte man die separat gemappten auch rückbauen weil die für das routing ja auch eher problematisch sind. Das rendering bleibt dann dank highway Flächen trotzdem “schön”.
Flo
Ne, da stimme ich dir nicht zu. Das Bein haben wir uns mit dem Datenmodell gestellt, welches nicht in der Lage ist Zusammenhänge zwischen Elementen richtig auszudrücken. Dafür waren zwar Relationen gedacht, aber es funktioniert nicht - wie du ja selber schreibst.
Für Fußgänger-Routing (*) ist das Gegenteil der Fall: Mit den separat gemappten Gehwegen ist das einfach, weil man den Routing-Graph direkt gegeben hat, mit drangetaggten Gehwegen treten hingegen massive Probleme beim Berechnen des Graphen auf und man muss in Kauf nehmen, dass der Graph am Ende fehlerhaft ist.
(*) Ich spreche von echtem Fußgängerrouting, nicht diesem Pseudo-Fußgängerrouting in der Fahrbahnmitte, das derzeit Standard ist.
naja, diese erstgenannten Relationen sind halt Routen von Straßen, man könnte z.B. Abbiegebeschränkungen theoretisch auch ohne Relationen mappen, z.B. indem man lokale Nummern für die Beschränkungen einführt, und dann sowas wie
no_right_turn=from_for_1;to_for_2 an einen highway taggt, no_right_turn=via_for_1 an den Node der Relation lokal 1, und no_right_turn=to_for_1 an den anderen way, etc. nur wäre das nicht unbedingt einfacher. Multipolygone könnte man ebenfalls so codieren, eigentlich gibt es nichts wofür man die Relationen benutzt, wo es mit ein paar Klimmzügen und etwas weniger stabil und schwieriger auszuwerten nicht auch ohne Relationen ginge
die type=area Relation hat sich halt nicht durchgesetzt
Also ich hab das noch nicht gesehen. Denn wir immer wenn wir dinge separat mappen ist nicht klar wo übergänge möglich sind. Das ist ja ein weiteres problem mit routing und separaten wegen.
Das ist ja auch bei jeder SoTM auch wieder Thema. Ich habe keine ahnung wie irgendwer das irgendwann lösen will. Separate wege haben halt andere probleme als alles als attribute an die wege zu packen.
Kaputt ist es in jedem fall, und ungelöst.
Flo
Ja, aber beide Erfassungsmethoden. Wir haben leider keine saubere Erfassungsmethode für Geh und Radwege.
Das einzige was ich bislang kenne ist Towards Realistic Pedestrian Route Planning von 2015. Das das so schwierig ist, dürfte vor allem auch daran liegen, dass Gehwege oft nicht separat erfasst werden - da beißt sich die Katze dann in den Schwanz… (Wir sehen uns ja in ein paar Tagen, da kann ich dir noch etwas mehr dazu erzählen - hier ist grad nicht der richtige Platz dazu.)
Das Problem existiert mit angetaggten Gehwegen genauso. Der Unterschied ist nur, dass man bei angetaggten Gehwegen davon ausgeht, dass Queren überall geht und bei separat getaggten, dass es nur an gemappten Querungen geht. Letzteres kann man ganz gut beheben, indem man informelle Querungsstellen ebenfalls mappt. Soweit ich weiß, gibt es mit den bekannten Bordmitteln bislang keine Möglichkeit, bei angetaggten Gehwegen anzugeben, dass man nicht queren kann.
Was eine Falsch-Interpretation ist. Diese Information ist beim sidewalk und cycleway Tagging schlichtweg nicht vorhanden. Die Tags besagen nur, dass es einen Geh- oder Radweg gibt. Mehr aber nicht.
Ohne Unterstützung im Editor ist das aber genauso fehlerbehaftet, wie das Verwalten einer Straßenrelation, minus dem Vorteil, dass man Teile der Daten nur einmal erfassen muss. Was ich damit meine ist: ich bin wirklich bekannt dafür Rechtschreibfehler zu machen, ich vertippe mich einfach andauernd und ohne Software merke ich das manchmal gar nicht. Einen Straßennamen wie “Friedrich-von-Bodelschwingh-Straße” an 50 Teilstücke von fahrbahnbegleitenden Rad- und Fußwegen via street:name=Friedrich-von-Bodelschwingh-Straße zu pappen ist einfach genauso fehleranfällig, wie die entsprechende Street-Raltion zu suchen und „hinzufügen“ zu sagen.
Es wäre allerdings extrem einfach, wenn ein Editor die Dazugehörigkeit richtig unterstützen würde und einen beim Erfassen eines begleitenden Fuß-/Radweges, oder einer neuen Fahrbahn zu fragen „hey, ist der Weg fahrbahnbegleitend? Wenn ja: zu welcher der X Straßen gehört er?“ oder „es gibt bereits eine Straßenrelation für die Straße mit Namen X. Soll Dein neues Teilstück hinzugefügt werden?“ Also so in etwa.
Der fast 10 Jahre alte Beitrag passt leider nicht auf das Problem der strukturierten Speicherung Straßen-begleitender Wege.
