Hi! Am 5. Dezember 2014 um 16:10 schrieb Tobias Knerr <o...@tobias-knerr.de>:
> Am 05.12.2014 13:19, schrieb Martin Vonwald: > > Vom Prinzip her ist bicycle:lanes=...|designated|... und > > cycleway:lanes=....|lane|.... identisch. Welche Variante besser ist, kann > > ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der > > Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes. > > Ich sehe hier einige Probleme: > * Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre > als forward/backward: Wie mappe ich Radwege, die in beide Richtungen > nutzbar sind? > Gute Frage, aber noch keine Antwort. Wobei ich mir hier gar keine Meinung zutraue ohne viele Beispiele gesehen zu haben. Solche Radwege ohne bauliche Trennung sind ja nicht so häufig. Daher sollten wir uns erstmal ansehen wann diese vorkommen um eine Idee vom Konzept dahinter zu bekommen. > * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut > werden? Wenn ja, wie? > Parkspuren theoretisch ja, auch wenn ich kein Freund davon bin. Gehsteige würde ich nein sagen, da es ja keine "Spuren" für irgendwas sind. Bei Gehsteigen würde ich bei dem bewährten Konzept mit den sidewalk-Tags (inkl. Sub-Tags und ohne separate Wege) bleiben. > * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es > nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf > die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur > mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das > anders? > Jeder der mit xxx:lanes-Tags arbeitet, sollte sich vorstellen, dass er nur die eine Spur sieht und gedanklich alle andere ausblenden und alle xxx:lanes-Tags zu xxx reduzieren. In deinem Beispiel bleibt dann ein "Weg" übrig, welcher nur für Radfahrer zulässig ist. Welche Breite würdest du annehmen für einen Weg, welcher nur für Radfahrer erlaubt ist? Das elegante an der :lanes-Erweiterung ist, das wir eigentlich keine neuen Schlüssel haben mir neuen Bedeutungen. Analog zu :forward/:backward definieren wir nur, dass der Wert eben nicht für den ganzen Weg. Der Suffix :forward/:backward ändert ja auch nicht die Bedeutung des Hauptschlüssels, sondern nur wofür er gilt. Bei :lanes ist es erst einmal das selbe (der einzelne(!) Wert gilt nur für eine Spur) mit der Erweiterung, dass wir die einzelnen Werte der einzelnen Spuren alle zusammen in den Wert des xxx:lanes-Schlüssels packen. Deshalb bin ich auch der Meinung, dass es keine Sonderbehandlung für xxx:lanes-Schlüssel geben sollte. Man muss nur die Werte auf die einzelnen Spuren zuweisen und dabei die xxx:lanes-Tags zu xxx reduzieren. Datenkonsumenten können dann die einzelnen Spuren ähnlich zu individuellen Wegen verarbeiten. bg, Martin _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
