Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 09.12.2014 um 08:55 schrieb Martin Vonwald: Am 8. Dezember 2014 um 11:55 schrieb 715371 osmu715...@gmx.de: Am 07.12.2014 um 19:26 schrieb Martin Vonwald: Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. Weil sich cycleway:width auf den Radweg bezieht Es ist ein highway=cycleway. ... der einen Gehweg mit Radweg - oder umgekehrt - identifiziert. und width sich auf den gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde). Mein Informationsstand ist, dass sich width bei Fahrbahnen immer auf die Fahrbahn bezieht und den Gehsteig nicht miteinbezieht. Der Gehsteig wird auch mit highway=cycleway, foot=designated beschrieben. Beides ist keine Fahrbahn. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 07.12.2014 um 19:26 schrieb Martin Vonwald: Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. Weil sich cycleway:width auf den Radweg bezieht und width sich auf den gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 07.12.2014 um 19:26 schrieb Martin Vonwald: Hi! Am 6. Dezember 2014 um 02:04 schrieb 715371 osmu715...@gmx.de: Was ist eigentlich mit solch einem Problem: https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg turn:lanes=left|through|cycleway:through|right ? Bitte fangt nicht an, die Bedeutung von turn zu verändern. Im Beispiel wäre es turn:lanes=left|through|through|right + bicylce:lanes=...|...|designated|yes BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder cycleway=track? Wobei letzteres nicht geht, weil ja schon cycleway=lane. Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn getrennt wäre? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder cycleway=track? Wobei letzteres nicht geht, weil ja schon cycleway=lane. Ich würde dort den Radweg seperat mit highway=cycleway/path + ... eintragen und den Radfahrsteifen als cycleway=lane. (Alternative kann ich mir auch cycleway:right=lane;track vorstellen, wobei ich bezweifel, dass das Richtig interpretiert wird. Oder auch cycleway:lanes=...|...|lane|... und cycleway:right=track) Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 07.12.2014 um 23:55 schrieb Tobias Knerr: Am 07.12.2014 19:19, schrieb Martin Vonwald: * 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. Momentan haben wir Tags für die normalen lanes, für die cycleways, für die parking:lanes, und für die sidewalks. Das Problem, das ich lösen will: Wie kann ich angeben, in welcher Ordnung die sich zueinander befinden? Ich kann mir da zwei Lösungen vorstellen: * Alles in die *:lanes=* mit integrieren * Zusätzlich zu den genannten Tags noch eine Liste taggen, die die Reihenfolge der genannten Elemente angibt Und ich versuche gerade, etwas nachzufühlen, was wohl besser ankommt. Halte es für einfacher und verständlicher mit *:lanes*=*. Was mir an der ganzen Diskussion bisher auffällt sind die wenigen exakten Beispiele. Denke, dort sollten wir anfangen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 08.12.2014 um 16:42 schrieb Hubert: Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder cycleway=track? Wobei letzteres nicht geht, weil ja schon cycleway=lane. Ich würde dort den Radweg seperat mit highway=cycleway/path + ... eintragen und den Radfahrsteifen als cycleway=lane. (Alternative kann ich mir auch cycleway:right=lane;track vorstellen, wobei ich bezweifel, dass das Richtig interpretiert wird. Oder auch cycleway:lanes=...|...|lane|... und cycleway:right=track) Wenn es keinen Grünstreifen gäbe, wäre die highway-Lösung aus meiner Sicht nicht unbedingt OK. Was ich mir wünschen würde, wäre ein gescheites Tagging für cycleway=lane;track. Man kann natürlich sagen, dass lane irgendwo auf die Fahrbahn gehört. Genauer könnte man das dann mit bicycle:lanes=...|... sagen. Und man könnte auch sagen, dass cycleway=track neben die Fahrbahn gehört. Vielleicht wäre das eine Lösung. BTW: Mit einem anderen Mapper sammle ich in Bremen zZ noch Beispiele: https://wiki.openstreetmap.org/wiki/Bremen/Radverkehrsanlagen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 8. Dezember 2014 um 11:55 schrieb 715371 osmu715...@gmx.de: Am 07.12.2014 um 19:26 schrieb Martin Vonwald: Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. Weil sich cycleway:width auf den Radweg bezieht Es ist ein highway=cycleway. und width sich auf den gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde). Mein Informationsstand ist, dass sich width bei Fahrbahnen immer auf die Fahrbahn bezieht und den Gehsteig nicht miteinbezieht. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
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
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 6. Dezember 2014 um 02:04 schrieb 715371 osmu715...@gmx.de: Was ist eigentlich mit solch einem Problem: https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg turn:lanes=left|through|cycleway:through|right ? Bitte fangt nicht an, die Bedeutung von turn zu verändern. Im Beispiel wäre es turn:lanes=left|through|through|right + bicylce:lanes=...|...|designated|yes Würdet ihr Barrieren wie Zäune, die zwischen Fahrbahn und Radweg (cycleway=track) stehen, als eigene Wege oder Knoten erfassen oder irgendwie anders? Ich gehe davon aus, dass cycleway=track gemappt ist. Als Wege. Ich verstehe deine Frage nicht wirklich: wie sonst? Einen Zaun haben wir schon immer als Weg erfasst. Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei einem stinknormalen Radweg die Breite taggen? Gibt es. Z. B. hier: https://www.openstreetmap.org/way/293395597 Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 6. Dezember 2014 um 10:36 schrieb Tom Pfeifer t.pfei...@computer.org: turn:lanes=left|through|cycleway:through|right ? Auch ein guter Vorschlag, hier kann der Renderer sich auf die Bezeichner konzentrieren die er kennt, und alle Spuren ignorieren, die ihm unbekannt sind, insbesondere müssen nicht vorher alle access-Matrizen geparst werden. Nein, ganz im Gegenteil, das ist ein sehr schlechter Vorschlag. Und die access-Tags müssen sowieso geparst werden. Wenn man das alles einheitlich und konsistent erfasst, ist es auch in der Verarbeitung keine Zauberei mehr. Wenn man natürlich hier und dort und da Sonder-Tags und Ausnahmen und Spezial-Reglen macht, dann und erst dann wird es so richtig lustig. Bitte! Ja, bitte: Haltet die Werte sauber. Sonst wird das nichts. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 07.12.2014 19:19, schrieb Martin Vonwald: * 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. Momentan haben wir Tags für die normalen lanes, für die cycleways, für die parking:lanes, und für die sidewalks. Das Problem, das ich lösen will: Wie kann ich angeben, in welcher Ordnung die sich zueinander befinden? Ich kann mir da zwei Lösungen vorstellen: * Alles in die *:lanes=* mit integrieren * Zusätzlich zu den genannten Tags noch eine Liste taggen, die die Reihenfolge der genannten Elemente angibt Und ich versuche gerade, etwas nachzufühlen, was wohl besser ankommt. * 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? Ich würde normal gar nicht auf die access-Tags sehen, wenn ich die Breite eines Weges bestimme, sondern nur auf den highway-Wert und width. Das funktioniert auch bei normalen Wegen gut genug, aber bei den Spuren lande ich so eben auch bei Radspuren bei der Standardbreite normaler Spuren. Das will ich jetzt nicht zum prinzipiellen Problem aufbauschen, nur fände ich es gut, wenn man das klarstellen könnte. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
715371 wrote on 2014-12-06 02:04: Was ist eigentlich mit solch einem Problem: https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg So eine Konstellation war ja wohl die einleitende Frage in diesem Thread :-) turn:lanes=left|through|cycleway:through|right ? Auch ein guter Vorschlag, hier kann der Renderer sich auf die Bezeichner konzentrieren die er kennt, und alle Spuren ignorieren, die ihm unbekannt sind, insbesondere müssen nicht vorher alle access-Matrizen geparst werden. Für die Breite gibt es width:lanes*=* Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei einem stinknormalen Radweg die Breite taggen? Gibt es. Z. B. hier: https://www.openstreetmap.org/way/293395597 Wenn ulamm das nachgemessen hat kann er das ja gern auch ranschreiben, wobei mir 1.6m nicht sehr ungewöhnlich erscheint. Aber ich habe hierzulande schon 4 m breite Fahrradalleen gesehen ;-) Tom ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Nur zum Verständnis: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). Aber an der Definition von lanes können wir jetzt nichts mehr ändern. Um genau diese Unklarheiten zu vermeiden werden bei xxx:lanes-Schlüsseln alle Spuren betrachtet. Ausnahmslos. Was man sieht, das mappt man. Dann gibt es keine Unklarheiten und hoffentlich weniger Fehler. Übrigens sehe ich auch nicht die Notwendigkeit irgendwie die lanes=x Angaben mit jenen der xxx:lanes-Angaben in Verbindung zu bringen. Je nach dem was ich benötige und was vorhanden ist, kann ich das eine oder das andere Auswerten. Eine Notwendigkeit beides gleichzeitig auszuwerten sehe ich nicht. Wenn ich an einen Spurassistenten denke, dann würde ich zuerst die xxx:lanes-Angaben verwenden und wenn es diese nicht gibt die lanes=x Angaben (mit zusätzlichen Annahmen) und wenn es diese auch nicht gibt, dann eben nur sinnvolle Annahmen treffen. Wozu xxx:lanes und lanes=x gleichzeitig auswerten? Die einzige Anwendung dafür sehe ich bei Prüfprogrammen, z.B. lanes=x kann nicht größer sein als die Anzahl der Werte eines xxx:lanes-Schlüssels. bg, Martin P.S. Ich unterstelle, dass die lanes=x und xxx:lanes-Angaben vollständig sind. Wenn man z.B. nur turn:lanes=left|through|right hat und lanes=2, dann stimmt etwas nicht, denn es fehlt die Angabe welche Spur nicht für den motorisierten Verkehr ist. Aber dies ist ein unvollständiges Tagging und kein Mangel des Taggingschemas. Ich würde in so einem Fall übrigens davon ausgehen, dass lanes=2 falsch ist, da diese Angaben so wie sie aktuell in der Datenbank sind, gerade in Kreuzungs- und Ab/Auffahrtsbereichen oft inkonsistent sind, da bis vor kurzem noch kaum jemand einen Weg extra aufsplittete, nur weil hier kurz mal ein Verzögerungsstreifen o.ä. ist. Diese Situation bessert sich erst seit kurzem, vor allem seit wir auch ein Schema haben um erlaubte Spurwechsel anzugeben. Am 4. Dezember 2014 um 16:53 schrieb chris66 chris66...@gmx.de: Am 04.12.2014 13:44, schrieb Martin Vonwald: Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. korrekt, so steht's auch im ursprünglichen Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 5. Dezember 2014 um 09:05 schrieb Martin Vonwald imagic@gmail.com: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. +1 So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). +1, das ist ähnlich wie bei den building_levels, da werden auch nicht einfach die Stockwerke des getaggten Objekts gezählt, sondern irgendwie sollen die Stockwerke von benachbarten Gebäuden/Gebäudeteilen vererbt werden (wie man es macht, wenn die unterschiedlich sind, ist komplett unklar AFAIK), und dann noch die building:min_levels abgezogen, wobei Dachgeschosse und Untergeschosse nicht zählen. Im Ernst, das ist die aktuelle Definition [1]. Bei den building:min_levels ist auch nicht klar, von welchem Gebäude die gezählt werden, das funktioniert nur in einfachen Situationen wie dem Wiki-Beispiel, wo alle Geschosshöhen gleich sind. Aber an der Definition von lanes können wir jetzt nichts mehr ändern. jein, vielleicht könnte man das doch noch tun. Unser Projekt ist gerade mal 10 Jahre alt, und wird sicherlich noch eine Vielzahl dessen weiterbestehen. Wenn wir jetzt ein paar Fehlentscheidungen (sofern man sich darüber einig ist, dass es eine Fehlentscheidung war) korrigieren, wäre das sicherlich mittel- und langfristig gut. Gruß, Martin [1] http://wiki.openstreetmap.org/wiki/Key:building:levels ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 05.12.2014 10:50, schrieb Martin Koppenhoefer: jein, vielleicht könnte man das doch noch tun. Unser Projekt ist gerade mal 10 Jahre alt, und wird sicherlich noch eine Vielzahl dessen weiterbestehen. Wenn wir jetzt ein paar Fehlentscheidungen (sofern man sich darüber einig ist, dass es eine Fehlentscheidung war) korrigieren, wäre das sicherlich mittel- und langfristig gut. Bestehende Tags umzudefinieren halte ich für die schlechteste Lösung. Besser wäre ein neues Tag einzuführen, z.B. lanes_all=n. Aber erstmal sollte man mit dem bestehenden Schema Erfahrungen sammeln, und schauen ob die Auswerter damit einen funktionierenden (auch bei komplizierten Kreuzungen) Spurassi hin bekommen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Martin Vonwald wrote on 2014-12-05 09:05: Nur zum Verständnis: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). Ja gut, dann sind wir uns ja doch einig. Die von Chris zitierte Proposal-Seite, unter Common questions, https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag sieht ja das lanes=N tag quasi nur für die Rückwärtskompatibilität. Das darüberstehende Beispiel benutzt cycleway:lanes:...=, während https://wiki.openstreetmap.org/wiki/Bicycle hier bicycle:lanes= einführt? Das Beispiel B1 ist besonders unglücklich, da es beim Spurlayout kein forward/backward benutzt. Ohne die lanes=3 + lanes:forward=2 bin ich komplett ratlos in welche Richtung die Spuren gehen. Selbst wenn ich das kenne, muss ich aus bicycle:lanes=designated vermuten dass designated eine Halbspur ist (falls nicht auch noch ein Bus mit langfährt), während yes eine Vollspur benutzt. Nun kann ich die beiden bicycle=designated subtrahieren und komme auf die Vollspuren, die ich nun endlich dem lanes=count zuordnen kann. Implementiere das mal bitte jemand auf einem Android. Wenn das fertig ist, kommt noch die Variante, falls die Rad/Busspur zufällig rechts aussen ist, das als cycleway:right=share_busway zusammenzufassen (B3). B4 erfindet noch service=bus obwohl das ja ein access-Recht ist und keine Art der Strasse. Aber an der Definition von lanes können wir jetzt nichts mehr ändern. Um genau diese Unklarheiten zu vermeiden werden bei xxx:lanes-Schlüsseln alle Spuren betrachtet. Ausnahmslos. Was man sieht, das mappt man. Dann gibt es keine Unklarheiten und hoffentlich weniger Fehler. Übrigens sehe ich auch nicht die Notwendigkeit irgendwie die lanes=x Angaben mit jenen der xxx:lanes-Angaben in Verbindung zu bringen. Je nach dem was ich benötige und was vorhanden ist, kann ich das eine oder das andere Auswerten. Eine Notwendigkeit beides gleichzeitig auszuwerten sehe ich nicht. Wenn ich an einen Spurassistenten denke, dann würde ich zuerst die xxx:lanes-Angaben verwenden und wenn es diese nicht gibt die lanes=x Angaben (mit zusätzlichen Annahmen) und wenn es diese auch nicht gibt, dann eben nur sinnvolle Annahmen treffen. Wozu xxx:lanes und lanes=x gleichzeitig auswerten? Die einzige Anwendung dafür sehe ich bei Prüfprogrammen, z.B. lanes=x kann nicht größer sein als die Anzahl der Werte eines xxx:lanes-Schlüssels. bg, Martin P.S. Ich unterstelle, dass die lanes=x und xxx:lanes-Angaben vollständig sind. Wenn man z.B. nur turn:lanes=left|through|right hat und lanes=2, dann stimmt etwas nicht, denn es fehlt die Angabe welche Spur nicht für den motorisierten Verkehr ist. Aber dies ist ein unvollständiges Tagging und kein Mangel des Taggingschemas. Ich würde in so einem Fall übrigens davon ausgehen, dass lanes=2 falsch ist, da diese Angaben so wie sie aktuell in der Datenbank sind, gerade in Kreuzungs- und Ab/Auffahrtsbereichen oft inkonsistent sind, da bis vor kurzem noch kaum jemand einen Weg extra aufsplittete, nur weil hier kurz mal ein Verzögerungsstreifen o.ä. ist. Diese Situation bessert sich erst seit kurzem, vor allem seit wir auch ein Schema haben um erlaubte Spurwechsel anzugeben. Am 4. Dezember 2014 um 16:53 schrieb chris66 chris66...@gmx.de: Am 04.12.2014 13:44, schrieb Martin Vonwald: Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. korrekt, so steht's auch im ursprünglichen Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 5. Dezember 2014 um 12:38 schrieb Tom Pfeifer t.pfei...@computer.org: Martin Vonwald wrote on 2014-12-05 09:05: Nur zum Verständnis: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). Ja gut, dann sind wir uns ja doch einig. Die von Chris zitierte Proposal-Seite, unter Common questions, https://wiki.openstreetmap.org/wiki/Proposed_features/ lanes_General_Extension#The_issues_with_the_lanes_tag sieht ja das lanes=N tag quasi nur für die Rückwärtskompatibilität. Ich war mir beim Schreiben des Proposals dieses Problems schon bewusst und habe deshalb extra darauf hingewiesen. Der Schlüssel lanes ist meiner Meinung nach broken-by-design. Das darüberstehende Beispiel benutzt cycleway:lanes:...=, während https://wiki.openstreetmap.org/wiki/Bicycle hier bicycle:lanes= einführt? 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 denke hier sollten die Mapper mit Nutzungszahlen abstimmen. Gültig sind aber beide Varianten, das sollten Datenkonsumenten berücksichtigen. Das Beispiel B1 ist besonders unglücklich, da es beim Spurlayout kein forward/backward benutzt. Ohne die lanes=3 + lanes:forward=2 bin ich komplett ratlos in welche Richtung die Spuren gehen. Selbst wenn ich das kenne, muss ich aus bicycle:lanes=designated vermuten dass designated eine Halbspur ist (falls nicht auch noch ein Bus mit langfährt), während yes eine Vollspur benutzt. Nun kann ich die beiden bicycle=designated subtrahieren und komme auf die Vollspuren, die ich nun endlich dem lanes=count zuordnen kann. Beispiel B1 ist unvollständig und daher nicht sinnvoll zu interpretieren. Die :lanes-Varianten sind hier sicher von mir, allerdings konnte ich hier nie fertig editieren, da mir der selbst ernannte Wächter der Seite sofort wieder herum editierte und no consensus vor die Nase geknallt hat und ich dazu definitiv keine Lust hatte. Korrekt wäre B1 wohl so: lanes=3 lanes:forward=2 lanes:backward=1 lanes:bus:forward=1 lanes:taxi:forward=1 vehicle:lanes:forward=yes|no|no bicycle:lanes:forward=no*|designated|no bus:lanes:forward=yes|no|designated taxi:lanes:forward=yes|no|designated vehicle:lanes:backward=yes|no bicycle:lanes:backward=no*|designated * Ob yes oder no kann ich ohne weitere Infos nicht entscheiden. Implementiere das mal bitte jemand auf einem Android. Wenn das fertig ist, kommt noch die Variante, falls die Rad/Busspur zufällig rechts aussen ist, das als cycleway:right=share_busway zusammenzufassen (B3). Ich denke, das macht auf jedem OS Probleme, da B1 einfach nicht korrekt ist. B3 würde ich analog zu B1 taggen: lanes=3 lanes:forward=2 lanes:backward=1 lanes:bus:forward=1 lanes:taxi:forward=1 vehicle:lanes:forward=yes|no bicycle:lanes:forward=no|designated bus:lanes:forward=yes|designated taxi:lanes:forward=yes|designated vehicle:lanes:backward=yes|no bicycle:lanes:backward=no|designated B4 erfindet noch service=bus obwohl das ja ein access-Recht ist und keine Art der Strasse. Um ehrlich zu sein, würde ich diese Seite generell einfach ignorieren. Wer Lust auf Edit-Wars hat, möge hier natürlich mit Freude eintauchen. ;-) bg, Martin P.S: Die Taggings habe ich jetzt mal schnell ohne viel Kontrolle runtergetippt; man möge mir Fehler verzeihen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
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? * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut werden? Wenn ja, wie? * 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? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 05.12.2014 um 16:10 schrieb Tobias Knerr: 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? Entweder als separaten Weg und bicycle=use_sidepath oder mit einer Kombination aus left/right + forward/backward. * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut werden? Wenn ja, wie? Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und parking:lane:lanes*=* vorstellen Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch unterbrochene fence_type=railing * 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? Für die Breite gibt es width:lanes*=* cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 05.12.2014 18:56, schrieb fly: Am 05.12.2014 um 16:10 schrieb Tobias Knerr: * 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? Entweder als separaten Weg und bicycle=use_sidepath oder mit einer Kombination aus left/right + forward/backward. Ich denke hier natürlich konkret an den Fall, dass ich diesen Radweg in die *:lanes=* mit einbauen will. Wie habe ich mir diese Kombination vorzustellen? Es muss ja weiterhin bicycle:lanes:forward/backward verwendet werden, oder? Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und parking:lane:lanes*=* vorstellen Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch unterbrochene fence_type=railing Falls das konsensfähig ist, wäre es natürlich eine schöne Möglichkeit. Das Problem der Interaktion mit explizit eingetragenen Barrieren gibt es ja ohnehin auch beim klassischen sidewalk- und parking:lane-Tagging. Und bei separaten Ways hat man ganz andere, viel größere Probleme... * 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? Für die Breite gibt es width:lanes*=* Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei einem stinknormalen Radweg die Breite taggen? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Moin, Am 05.12.2014 um 20:48 schrieb Tobias Knerr: Am 05.12.2014 18:56, schrieb fly: Am 05.12.2014 um 16:10 schrieb Tobias Knerr: * 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? Entweder als separaten Weg und bicycle=use_sidepath oder mit einer Kombination aus left/right + forward/backward. Ich denke hier natürlich konkret an den Fall, dass ich diesen Radweg in die *:lanes=* mit einbauen will. Wie habe ich mir diese Kombination vorzustellen? Es muss ja weiterhin bicycle:lanes:forward/backward verwendet werden, oder? Was ist eigentlich mit solch einem Problem: https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg turn:lanes=left|through|cycleway:through|right ? Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und parking:lane:lanes*=* vorstellen Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch unterbrochene fence_type=railing Falls das konsensfähig ist, wäre es natürlich eine schöne Möglichkeit. Das Problem der Interaktion mit explizit eingetragenen Barrieren gibt es ja ohnehin auch beim klassischen sidewalk- und parking:lane-Tagging. Und bei separaten Ways hat man ganz andere, viel größere Probleme... Würdet ihr Barrieren wie Zäune, die zwischen Fahrbahn und Radweg (cycleway=track) stehen, als eigene Wege oder Knoten erfassen oder irgendwie anders? Ich gehe davon aus, dass cycleway=track gemappt ist. * 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? Für die Breite gibt es width:lanes*=* Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei einem stinknormalen Radweg die Breite taggen? Gibt es. Z. B. hier: https://www.openstreetmap.org/way/293395597 LG 715371 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hallo Martin, danke für die Antwort. Hab mir das gerade am Beispiel der Freiburger Kronenbrücke abgeschaut. Danke dass du meine Gedanken nochmal bestätigst! Liebe Grüße Benjamin On 04.12.2014 12:34, Martin Vonwald wrote: Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Ich halte das Tagging in der beschriebenen Form für inkonsistent, genau aus dem von Martin unten beschriebenen Grund, lanes sind Vollspuren für zweispurige Fahrzeuge. lanes=n und die Anzahl der turn:lanes sollten daher zueinander passen, andernfalls ist der Router überfordert und wird das Tagging für diese Kreuzung als fehlerhaft verwerfen. Das diskutieren wir grade in OsmAnd wo derzeit die turn:lanes-layouts eingebaut werden. Schaut auch bitte mal die Beispiele (no consensus) an auf https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_and_bus.2Ftaxi_lanes In Beispiel B1, deckt mal die Skizze zu und versucht es aus dem Tagging zu rekonstruieren. Ich bekomme 3 lanes angeboten, eine backward, zwei forward, und habe dann jeweils 5 Werte für access die ich irgendwo nach rechts oder links schieben kann. Ich halte daher das Problem der zwischengelagerten Halbspuren für ungelöst. Vermutlich muss das turn:lanes-Schema um entsprechende Werte für Halbspuren ergänzen. Tom Benjamin Grimm-Lebsanft wrote on 2014-12-04 13:15: Hallo Martin, danke für die Antwort. Hab mir das gerade am Beispiel der Freiburger Kronenbrücke abgeschaut. Danke dass du meine Gedanken nochmal bestätigst! Liebe Grüße Benjamin On 04.12.2014 12:34, Martin Vonwald wrote: Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. Du musst überhaupt nichts hin und herschieben, du hast alle Informatione. Kein Widerspruch. Nicht inkonsistent. Am 4. Dezember 2014 um 13:36 schrieb Tom Pfeifer t.pfei...@computer.org: Ich halte das Tagging in der beschriebenen Form für inkonsistent, genau aus dem von Martin unten beschriebenen Grund, lanes sind Vollspuren für zweispurige Fahrzeuge. lanes=n und die Anzahl der turn:lanes sollten daher zueinander passen, andernfalls ist der Router überfordert und wird das Tagging für diese Kreuzung als fehlerhaft verwerfen. Das diskutieren wir grade in OsmAnd wo derzeit die turn:lanes-layouts eingebaut werden. Schaut auch bitte mal die Beispiele (no consensus) an auf https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_ and_bus.2Ftaxi_lanes In Beispiel B1, deckt mal die Skizze zu und versucht es aus dem Tagging zu rekonstruieren. Ich bekomme 3 lanes angeboten, eine backward, zwei forward, und habe dann jeweils 5 Werte für access die ich irgendwo nach rechts oder links schieben kann. Ich halte daher das Problem der zwischengelagerten Halbspuren für ungelöst. Vermutlich muss das turn:lanes-Schema um entsprechende Werte für Halbspuren ergänzen. Tom Benjamin Grimm-Lebsanft wrote on 2014-12-04 13:15: Hallo Martin, danke für die Antwort. Hab mir das gerade am Beispiel der Freiburger Kronenbrücke abgeschaut. Danke dass du meine Gedanken nochmal bestätigst! Liebe Grüße Benjamin On 04.12.2014 12:34, Martin Vonwald wrote: Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 04.12.2014 13:44, schrieb Martin Vonwald: Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. korrekt, so steht's auch im ursprünglichen Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
