Nein, wir taggen nicht für Router oder Renderer, sondern die Wirklichkeit. Und der Straßenname bezieht sich auf die Straße (bestehend aus Fahrbahn, Geh-/Radweg, Grünstreifen etc.)
Wenn der Renderer nun die Kartenansicht “verunstaltet”, weil er auch den Straßennamen auf dem Radweg anzeigt, ist das Problem dort zu lösen.
Persönlich find ich den Straßennamen nur an der Fahrbahn eleganter, vor allem wegen Redundanz.
Der Vorschlag is_sidepath=[Straßenname] hat zwar auch was, ist aber im Prinzip das selbe in grün, nur dass es nicht gerendert wird.
Ich gestehe ja offen ein, dass ich mich mit Radwege-tagging und -Routing noch nie im Leben ernsthaft auseinandergesetzt habe,
aber kann mir mal jemand der sich damit auskennt erklären, warum es drei Tags benötigt:
highway=path
[…]
cycleway=sidepath
footway=sidewalk
name=Lerchenauer Straße
[…]
Für eine Information, die sich verlustfrei in einem einzigen Tag ablegen lässt:
highway=path
[…]
is_sidepath=Lerchenauer Straße
[…]
Wenn man Redundanzen auf dem Level vermeiden will, müsste man den name-tag in eine street-Relation auslagern.
Nun, neben den schon genannten Gründen ist “is_sidepath” nicht dafür gedacht gewesen.
Des Weiteren ist “footway=sidewalk” im Gegensatz zu “is_sidewalk” (und zu “=sidepath”) schon weit verbreitet. Vor allem in Verbindung mit “highway=footway”. Es gibt außerdem auch noch “footway=crossing”. Bei “highway=path” wäre meiner Ansicht nach “path=sidepath/crossing” sinnvoller bzw logischer.
Hinzu kommen allgemeine Überlegungen, angefangen bei “Don’t tag for …” bis zu Datenbankaufbau und Auswertungen. “=sidepath” und “=sidewalk” sind hier nur Werte und werden automatisch übernommen, da die Schlüssel “cycleway” und “footway” allgemein gebräuchlich und daher in den meisten DB schon vorhanden sind. Dies ist bei “is_sidepath” nicht der Fall.