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] Screencast-Programm
Am 05.12.2014 07:35, schrieb Peter Schmidt: Am besten ist es, wenn du 2 Monitore hast, da es sonst zu Aufnahmefehlern kommen kann, wenn sich die Fenster von OBS und dem Programm, was du aufnehmen willst, überschneiden. Na ja, es entsteht dann halt der berühmte Kamera-filmt-Monitor Feedbackeffekt. Der ist in der Digitalausführung allerdings bei weitem nicht so beeindruckend wie in der Analogversion. :) https://www.youtube.com/watch?v=mKK-q3yjph4 Chris ___ 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] Skandal: Nissum Fjord einfach weg?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05.12.2014 08:01, Elstermann, Mike wrote: https://geoobserver.wordpress.com/2014/12/05/skandal-nissum-fjord-einfach-weg/ Nissum Fjord fehlt bei Bing und GoogleMaps. Die frohe Botschaft, bei OSM ist der Fjord verlässlich vorhanden! :-) ALSO OSM! Allerdings: Wenn er bei Google doch mal da ist, dann kann man auf der Karte auch nachlesen, wie er heißt. Bei OSM ist der Fjord noch ein Punkt mit natural=water, was erst bei witzlos hohem Zoom angezeigt wird. Auch bei uns gibt es also noch zu tun (natürlich den Fjord als Fläche eintragen, nicht die Anzeige von natural=water ändern). Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUgYlUAAoJEBrjxFVQEkD/zKAP/1ZGxmi8yXJ1T3Xk4p0zzCvb sBZsQIly3lxv9GDMbrLCxYybDFxX6iPW3/jUTw5++/D9oNon0uVIB5gAqGdw8HVT YDUPoIuRLbPKU0206DviDDtk4JE1pYv1QLFqV9jJyxGmNiGkqjF4pNRITnER+2xp PZJMpZeDwOcFF+JoZNILMJqo6cNvheB0l9rU+9naAdkOWZnlsyA2o/QQkrnbIqSu /4Qo1C5iB+UBBeRp62pzigIiqyiQrnI8NDwsDdxrNBuhM7D1VIysPSo/rkXjGq3e DtMT5UJf44GNqYsewahjbUFna7IXR8tv+F7H1sxx2vtedwiVG53j0qLHAAPTn12t mqR2sqGhAo9BVboRmFGz/oMAttJmvOObQWe1I0jkCJaK3MHbLejtBOxDBtiDofjv hZZvlv0ugjSkdyTPkhC9uEsYTMUwX7IV3tVySek7l0kwIXEfj5cq9Tx7rIrg87dH 6H2kJ9/WSK7BQffmPDDGKTlzEo2Ib/BOWai82ytdlRFKogbhHg75i+BFU02qcRYH jWWAigSuuwhEKUuuBi1Gks4LIt32mYlDxVL62bOAx/oKvGfHdbVy7VBj498zNmIk Xj1Izv+5s1fVqVFV04A8kdiv2LSKI29dqVKn0F19iBOm7S0I37BgAlhg3yQJ6wvF QKNlgEfpMcYNKcmjHb9B =Xm9g -END PGP SIGNATURE- ___ 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
