[Talk-de] Draft für lanes Proposal
Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 10:44, schrieb Martin Vonwald: Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Man sollte sich noch einmal über die :forward/:backward-Aufteilung Gedanken machen. Ich finde sie spontan etwas fragwürdig, weil sich eben etliche Straßen nicht in zwei Hälften mit jeweils einheitlicher Fahrtrichtung aufteilen lassen. Das hast du teilweise ja schon im Proposal selber zugegeben. Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Damit in Zusammenhang stehen die lanes:both (die bei left/right wohl lanes:center heißen würden). Ich halte es übrigens für eine schlechte Idee, mehr als eine solche Spur zu erlauben, weil nicht klar ist, in welcher Reihenfolge sie dann angegeben würden. Ein paar Klarstellungen wären noch gut: * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. * left/right als Werte von turn:lanes sind immer in Fahrtrichtung gemeint, d.h. eine Linksabbiegerspur ist unabhängig von der OSM-Wayrichtung immer left? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 10:44, schrieb Martin Vonwald: Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Man sollte sich noch einmal über die :forward/:backward-Aufteilung Gedanken machen. Ich finde sie spontan etwas fragwürdig, weil sich eben etliche Straßen nicht in zwei Hälften mit jeweils einheitlicher Fahrtrichtung aufteilen lassen. Das hast du teilweise ja schon im Proposal selber zugegeben. Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Damit in Zusammenhang stehen die lanes:both (die bei left/right wohl lanes:center heißen würden). Ich halte es übrigens für eine schlechte Idee, mehr als eine solche Spur zu erlauben, weil nicht klar ist, in welcher Reihenfolge sie dann angegeben würden. Ein paar Klarstellungen wären noch gut: * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung bzw. für :both von links nach rechts in OSM-Way-Richtung. * left/right als Werte von turn:lanes sind immer in Fahrtrichtung gemeint, d.h. eine Linksabbiegerspur ist unabhängig von der OSM-Wayrichtung immer left? Korrekt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 14:50, schrieb Martin Vonwald: Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: direction:lanes:forward=forward|forward|both|forward Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Der eine konkrete Unterschied bei den Auswirkungen kommt nur beim Linksverkehr zum Tragen. * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. bzw. für :both von links nach rechts in OSM-Way-Richtung. Dann hat man aber doch ein Problem, wenn man den Way umdreht. Ich hatte aufgrund deiner Formulierungen im Proposal (Big problem here! If the way is reversed the direction information is destroyed.) bisher eigentlich angenommen, dass du mit der Unterteilung des Spurlayouts in zwei (oder drei) Teile gerade das vermeiden wolltest. Wenn du gar kein Problem damit hast, dass die Sortierung der Spuren von der OSM-Way-Richtung abhängig ist, verstehe ich nicht mehr, warum du nicht direkt alle Spuren von links nach rechts in ein Tag packst? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Hallo, Am 03.02.2012, 15:23 Uhr, schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 14:50, schrieb Martin Vonwald: Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: Ich habe mir damals bei dem parking:lane-Proposal viele Gedanken gemacht zum Thema forward/backward vs. left/right. Damals gab es vornehmlich nur forward/backward. Die Idee, left/right einzuführen begab sich aus der Notwendigkeit heraus, Dinge links und rechts der Straße darzustellen, und zwar insbesondere in dem Falle, dass es sich um eine Einbahnstraße handelt. Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Ein Problem mit Linksverkehr ergibt sich bei beiden Möglichkeiten eigentlich nicht. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 3. Februar 2012 15:23 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 14:50, schrieb Martin Vonwald: Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: direction:lanes:forward=forward|forward|both|forward Dieses Beispiel stellt ja einen Spezialfall dar und wie beschrieben ist das :forward dort eigentlich unnötig und wird nur verwendet, damit die Spurrichtungen nicht zerstört werden, wenn der Weg umgedreht wird. Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Hm... dem kann ich nicht folgen. Es gibt in OSM z.B. lanes:forward=2 - das sagt uns, dass es zwei Spuren gibt, welche in die selbe Richtung führen wie der OSM-Way. Ich möchte hier ein bekanntes Konzept verwenden und :forward/:backward ist so eines. Ich muss offen zugeben, dass ich vor dem heutigen Tag noch nie etwas von :left/:right gehört oder gesehen habe. Genau schon wie bei der kurzen Diskussion um den ; gilt auch hier: dieses Proposal definiert hier nichts um. Und das soll es ja auch nicht. Spuren in Wegrichtung wurden bisher als :forward getaggt und das sollen sie auch weiterhin. Spuren gegen die Wegrichtung wurden bisher als :backward getaggt und das sollen sie auch weiterhin. Dieses Proposal gibt dir nur die Möglichkeit Eigenschaften für diese Spuren anzugeben. Der obige Spezialfall ist übrigens gar nicht so unlogisch, denn das :forward am Ende bedeutet ja nach aktuellem Verständnis, dass wir Eigenschaften in Richtung des OSM-Ways definieren. Wenn die Spur nun in diese Richtung verläuft, ist sie eine forward-Spur. Verläuft sie entgegen dieser Richtung eben eine backward-Spur. Das Beispiel ist nicht hübsch, aber es sollte nur sehr selten notwendig sein sowas zu taggen. Der eine konkrete Unterschied bei den Auswirkungen kommt nur beim Linksverkehr zum Tragen. * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. Nur du verlierst die Information über die Fahrtrichtung! Und diese Information ist viel wichtiger als die Information ob die Vorwärts-Spuren links oder rechts sind: Wenn ein Router keine Ahnung hat ob wir Rechts- oder Links-Verkehr haben, kann er mit :forward/:backward trotzdem korrekte Routen berechnen, er kann nur keine Penaltys für das Linksabbiegen bei Rechtsverkehr (und umgekehrt) vergeben. Wenn ein Router wiederum keine Ahnung hat ob wir Rechts- oder Links-Verkehrt haben, hat er mit :left/:right das unlösbare Problem, dass er nicht weiß, zu welcher Kreuzung die Abbiegespuren führen: zur nächsten oder zur vorherigen. Er weiß zwar wo welche Spuren liegen, kann aber mit diesen Information überhaupt nichts anfangen, da ihm die Richtung fehlt. bzw. für :both von links nach rechts in OSM-Way-Richtung. Dann hat man aber doch ein Problem, wenn man den Way umdreht. Welches? Ich hatte aufgrund deiner Formulierungen im Proposal (Big problem here! If the way is reversed the direction information is destroyed.) bisher eigentlich angenommen, dass du mit der Unterteilung des Spurlayouts in zwei (oder drei) Teile gerade das vermeiden wolltest. Wenn du gar kein Problem damit hast, dass die Sortierung der Spuren von der OSM-Way-Richtung abhängig ist, verstehe ich nicht mehr, warum du nicht direkt alle Spuren von links nach rechts in ein Tag packst? Die Sortierung muss irgendwie definiert sein. Auch wenn direkt alle Spuren von links nach rechts eingetragen werden, muss man definieren, wo links ist. Im allgemeinen geht man davon aus, dass dies aus Sicht der OSM-Weg-Richtung betrachten wird und damit hast du wieder deine Abhängigkeit. vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Danke, so habe ich es auch verstanden. Aus dieser Sicht ist es eigentlich klar, dass es :forward/:backward sein muss. Vielen Dank und vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 17:14, schrieb Martin Vonwald: Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Danke, so habe ich es auch verstanden. Aus dieser Sicht ist es eigentlich klar, dass es :forward/:backward sein muss. Hmm? Die von Kay beschriebene Regel entspricht im Grunde auch meiner Denkweise, und genau deshalb kritisiere ich doch deine Verwendung von :forward/:backward. Wenn sich (in Wayrichtung) rechts der Fahrbahn eine Radspur befindet, auf der Fahren in beide Richtungen erlaubt ist, dann ist die Spur permanent dort aufgemalt. Es handelt sich also *nicht* um eine Eigenschaft, die von der Flussrichtung des Verkehrs abhängt. Anders gesagt: Wir haben ein Tag zur Angabe der Lage der Spur. Mit Kenntnis der lokalen Regeln kann man aus der Lage auch den Default für die Fahrtrichtung des Verkehrs darauf ableiten, aber das ist nur eine abgeleitete Information und sie kann bei Bedarf per direction-Tag überschrieben werden. Die Lage ist die *primäre* Information. Ich hoffe, ich nerve nicht zu sehr. Aber aus meiner Sicht ist glasklar, dass hier :left/:right geeignet ist und du einfach falsch denkst. ;) Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Hmm? Die von Kay beschriebene Regel entspricht im Grunde auch meiner Denkweise, und genau deshalb kritisiere ich doch deine Verwendung von :forward/:backward. Kay schrieb: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. Ein Radspur mitten auf der Fahrbahn oder eine Straßenbahnspur befindet sich weder rechts noch links der Fahrbahn, sondern ist Teil dieser. * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Die Fahrspuren (Rad, Straßenbahn, ...) besitzen bewegenden Verkehr und es handelt sich um Vektoren, welche in die selbe oder entgegengesetzte Richtung des Ways gehen. Wenn sich (in Wayrichtung) rechts der Fahrbahn eine Radspur befindet, auf der Fahren in beide Richtungen erlaubt ist, dann ist die Spur permanent dort aufgemalt. Es handelt sich also *nicht* um eine Eigenschaft, die von der Flussrichtung des Verkehrs abhängt. Die Radspur hat eine Flussrichtung. Übrigens ist die Radspur nicht rechts der Fahrbahn sondern Teil dieser. Anders gesagt: Wir haben ein Tag zur Angabe der Lage der Spur. Mit Kenntnis der lokalen Regeln kann man aus der Lage auch den Default für die Fahrtrichtung des Verkehrs darauf ableiten, aber das ist nur eine abgeleitete Information und sie kann bei Bedarf per direction-Tag überschrieben werden. Die Lage ist die *primäre* Information. Die Lage ist wertlose Information, wenn du nicht weißt, was du dort machen darfst. Zusätzliche Informationen sollten so wenig wie möglich notwendig sein. Ich hoffe, ich nerve nicht zu sehr. Aber aus meiner Sicht ist glasklar, dass hier :left/:right geeignet ist und du einfach falsch denkst. ;) Du nervst nicht - wir diskutieren. Aber aus meiner Sicht ist glasklar, dass hier :forward/:backward geeignet ist und du einfach falsch denkst. ;) vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Ich zitiere auch noch mal aus einer deiner früheren Mails, weil ich den Eindruck habe, dass wir nicht dieselbe Anwendung im Kopf haben. Am 03.02.2012 17:12, schrieb Martin Vonwald: Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Hm... dem kann ich nicht folgen. Es gibt in OSM z.B. lanes:forward=2 - das sagt uns, dass es zwei Spuren gibt, welche in die selbe Richtung führen wie der OSM-Way. Ich möchte hier ein bekanntes Konzept verwenden und :forward/:backward ist so eines. Das bekannte Konzept muss hier zwangsläufig erweitert werden, weil wir bei einer Spur zwei Informationen vorliegen haben: * Wo liegt die Spur? * In welcher Richtung darf man darauf fahren? Es ist leicht zu übersehen, weil bei Autospuren hier wegen der gesetzlichen Regelungen normalerweise eine direkte Beziehung besteht, aber: Von der Lage war im alten Konzept noch gar nicht die Rede. In einem vollwertigen Spurkonzept muss sie aber wiedergegeben werden. Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. Nur du verlierst die Information über die Fahrtrichtung! Und diese Information ist viel wichtiger als die Information ob die Vorwärts-Spuren links oder rechts sind: Wenn ein Router keine Ahnung hat ob wir Rechts- oder Links-Verkehr haben [...] Du denkst anscheinend in erster Linie an Router. Bei denen hast du auch Recht, aber Router sollten sowieso die örtlichen Verkehrsregeln kennen. Renderer kennen sie in der Regel nicht und sollten sie auch nicht kennen müssen. Aber der Renderer will wissen, ob er z.B. auf der linken oder rechten Wayseite einen Streifen für Radspur zeichnen soll. In welcher Richtung man dort dann fährt, braucht er hingegen nicht wissen - das wird sich der Kartenbetrachter selbst erschließen. Hier kommen wieder meine beiden o.g. Eigenschaften der Spur ins Spiel: Lage der Spur und Fahrtrichtung. Ein Router sollte idealerweise beides wissen. Einem Renderer reicht hingegen oft die Lage. Und mit der innen-nach-außen-Regel kann man die Lage ermitteln, ohne die Fahrtrichtung zu kennen. Am 03.02.2012 18:58, schrieb Martin Vonwald: Ein Radspur mitten auf der Fahrbahn oder eine Straßenbahnspur befindet sich weder rechts noch links der Fahrbahn, sondern ist Teil dieser. Der Bezug zur Fahrbahn ist aus meiner Sicht nicht entscheidend. Sie befinden sich links/rechts der Mittellinie, auf die eine Straße in unserem Datenmodell reduziert wird. (Oder auf dieser, dann entsprechen sie einer center lane.) Vor dem Hintergrund des bisher Gesagten noch mal zusammengefasst meine Position: Ich will ausdrücken: * Lage der Spur * Fahrtrichtung des Verkehrs darauf. Die _Lage_ drücke ich aus, indem ich die Eigenschaften der Spuren links bzw. rechts meiner gedachten Mittellinie, geordnet nach Entfernung von dieser Mittellinie, als Wertliste aufschreibe. Für die _Fahrtrichtung_ nehme ich an, dass Spuren rechts der Mittellinie in Wegrichtung befahren werden, links davon entgegen der Wegrichtung. (Bei Linksverkehr umgekehrt.) Wo diese Annahme nicht zutrifft, setze ich die Fahrtrichtung ausdrücklich über ein direction-Tag. So, vielleicht hab ich's diesmal richtig erklärt, damit wir zumindest den anderen Standpunkt verstehen können. Ich merke aber, wie ich mich langsam emotional in meine Position eingrabe - und das ist nicht der beste Geisteszustand für eine konstruktive Diskussion. Daher werde ich für heute erst mal den Mund halten und morgen in Ruhe und mit etwas Abstand noch mal über unsere Positionen nachdenken. Vielleicht machst du ja dasselbe? :) Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Guten Morgen, Ich fasse das Ziel des aktuellen Proposals kurz zusammen: Definition der Eigenschaften einzelner Spuren. Da Proposal oft wegen zu hoher Komplexität abgelehnt werden, ist das Ziel bewusst niedrig gesteckt. Durch die Art wie das Proposal das erreichen will ergibt sich die Lage der Spuren innerhalb einer Fahrtrichtung. Die Lage der Fahrtrichtungen zueinander wird nicht definiert, kann bei Kenntnis von Rechts-/Links-Verkehr aber abgeleitet werden. Diese Information ist nicht Teil des Proposals (niedrige Komplexität), kann aber jederzeit durch z.B. ein Tag an den Landesgrenzen bzw. im Grenzbereich direkt am Way ergänzt werden. Dieses Proposal ist beabsichtigt einfach gehalten und vermeidet Umdefinitionen um den Stillstand in diesem Bereich zu beenden. Es ist eine Evolution der bestehenden Tags. So eine Vorgehensweise bringt nicht immer die hübschesten Lösungen, aber man muss immer im Hinterkopf haben was konsensfähig ist und was nicht. Am hübschesten wäre es, viele der bestehenden Tags zu verwerfen und von Grund auf neu zu definieren. Sind wir ehrlich: das wird nicht passieren. Ich habe deinen Standpunkt schon verstanden und bin mir des Problems auch bewusst (siehe Abschnitt Probleme im Proposal). Ich werde das Links-/Rechtsverkehrproblem noch einmal hervorheben und auf die Konsequenzen sowie die möglichen Lösungen hinweisen. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
