Ein alternatives Tagging zu street:name ist is_sidepath:of:name, wofür das OSM-Verkehrswende-Team (ich pinge mal @tordans und @Supaplex030) ein Proposal erarbeitet hat, das aktuell aber nicht weiterverfolgt wird:
Hmmm, warum zuzementiert und vorbei mit Änderungen?
Für die hiesige Kriegsstr. hat das mal irgendwer angefangen nach irgendeinem Modell und die sieht aktuell halbwegs brauchbar aus, nur am Mendelssohnplatz kleinere Fehlstellen …
Hast du auch mitgezählt, wie viele Leute an der Kriegsstraße was ändern wollten, und es wegen der Relation gelassen haben? Ich mein, die meiste Zeit gibt es vermutlich nicht viel Struktur zu ändern, aber wenn doch, dann wird es mit diesen Relationen halt so komplex, dass es sich die meisten Leute nicht mehr zutrauen und dann lieber nichts machen. - Das ist zumindest mein Eindruck bei den (Bus-)Routen und ich denke, das kann man auf solche Relationen übertragen.
Eine mMn noch nennenswerte Alternative ist das Konzept von alles umfassenden Straßenflächen (z. B. landuse=highway; area:highway eignet sich eher weniger dafür), aus denen sich für jeden Teil eines Linienbündels ein passender Straßenname ableiten lässt. Ein ausgearbeiteter, dokumentierter Vorschlag dafür ist mir aber nicht bekannt. (Siehe auch Proposal:Key:is_sidepath#Alternative_concepts_and_it’s_limitations)
I think since none of the >5 methods (see above) to record/derive street names on sidepaths is widely in use or accepted, only very specialized/experimental routing providers would have an incentive to use this kind of data.
IMHO this is a big gap in our data model, and closing it would have great potential.
Die Namen sind mir nicht das wichtigste an den separaten Wegen, ich lege da eher Wert auf Oberfläche, Beschaffenheit und Breite. Von daher bin ich auch offen für einen anderen Key.
Da ich sowieso is_sidepath erfasse, macht es wohl am meisten Sinn, auch is_sidepath:of und is_sidepath:of:name zu nutzen. Dazu gibt es ja immerhin ein Proposal. street:name ist zwar KISS, aber mich stört, dass man dann nicht auch street taggt.
Grundsätzlich zum Getrennt-Erfassen: Aus meiner Sicht hat es vor allem einen Mehrwert, wenn die Rad- und Fußwege detailliert getaggt werden, was an der Fahrbahnlinie nur mit kleinteiligem Schneiden möglich wäre, oder wenn z.B. Parkbuchten, Grünstreifen oder Bäume zwischen den beiden Wegen erfasst werden.
iD macht das doch schon mit Adressen, für solche Namen ließe sich die Funktionalität bestimmt übernehmen.
Nachtrag: Ich habe jetzt den JOSM-Preset is_sidepath von @skyper gefunden, der für is_sidepath:of:name und is_sidepath:of:ref existierende name bzw. ref als Autovervollständigung vorschlägt.
Danke für die Lorbeeren. Hatte echt schon vergessen, dass ich das, damals recht neue, Feature verwendet hatte.
So wie es aussieht, sollte ich die Beschreibungen mal etwas überarbeiten (major → main) und eventuell auch ins Deutsche übersetzten. Bin auch nicht böse, wenn das eine andere Person für mich übernimmt, da ich leider in letzter Zeit nicht so viel Zeit für OSM haben dafür aber etliche Baustellen.
Meiner Meinung nach sind das “Namen” (die Straße hat den Namen und dadurch auch die einzelnen “Spuren”), der primäre Grund warum viele es nicht einfach so taggen wollen (mit name) ist, dass man sonst den Namen mehrfach in der Karte gerendert sieht. Und das könnte man ganz einfach lösen, wie @ToniE bereits im 3. Beitrag dargelegt hat (indem man es bei Bedarf nicht rendert wenn es sich um footway=sidewalk oder cycleway=sidepath handelt).
Für die meisten straßenbegleitenden Wege mag das stimmen. Schwierig wird es, wenn der Feldweg entlang der Bundesstraße einen eigenen Namen hat oder ein straßenbegleitender Radweg in highway=service oder highway=residential mündet.
Ja, es lässt sich modellieren und diente als Beispiel, warum ich lieber generell is_sidepath:of:name anstatt name bei Trottoirs verwende.
Das Problem mit service/residential ist eigentlich das selbe wie beim Feldweg, nur dass hier die Wegabschnitte meist kürzere sind, welche auch als Seitenweg einer übergeordneten Straße angesehen werden.