Hallo, Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das "Problem der drehenden Wege" bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden.
Ich sehe da OSM einfach bei einer Grenze angekommen. - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von "Linienbündeln" und "Fahrspurtagging" gelesen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? ---------- Ich meine, aufgrund dieser unbefriedigenden Situation gibt es eigentlich immer nur eine Diskussion: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Bei genauerem Hinsehen, kommt immer das gleiche heraus: Uneinigkeit, weil es natürlich für beide Varianten Vor- und Nachteile gibt. Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) --------- Mein Vorschlag ist sicher nicht neu und ich behaupte _nicht_, damit den Stein der Weisen gefunden zu haben! 1. Die bisherige Struktur von Nodes und Ways wird beibehalten und kann bei Bedarf an bestimmten Stellen (hier nur für Straßen!) erweitert werden. 2. Diese Erweiterung für Straßen sollte auf diese Weise einfach (von Anwenderseite gesehen) möglich sein: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion "Gruppierung" nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. b) Diese way-Gruppe könnte in JOSM so dargestellt werden, dass jeder way beim Zeichnen automatisch parallel ausgerichtet wird und mit einer gemeinsamen Hintergrundfarbe hinterlegt ist. Das zeigt, das es sich um einen way im bisherigen Sinne ohne bauliche Trennung handelt. c) Festlegen der Richtung beider ways wie bisher auch und ein Schlosssymbol setzen, das verhindert, dass jemand diese Richtung ändern kann, ohne von JOSM rückgefragt zu werden. d) Taggen der entsprechenden Eigenschaften für die jeweilige Richtung. 3. Wenn man auf solch ein way-Gruppierung stößt, dann weiss man in DE, dass Rechtsverkehr herrscht und dann ist klar, in welcher Richtung -also auf welchem der beiden ways was getaggt weden muss, wenn man die Wirklichkeit abbilden möchte. 4. Es könnten mehrere ways für eine Fahrtrichtung in der Gruppe sein. Z.B. zwei zeigen in die eine Richtung, einer zeigt in die andere. Dadurch wäre auch Fahrspurtagging möglich und durch das Schlosssymbol in JOSM und Potlatch(?) wird man vorsichtig beim Ändern der Way-Richtung. 5. Nun muss noch was gegen die Redundanz gemacht werden: Anlegen eines "Datenways". a) Eine Straße, die z.B. je eine Fahrspur in jeder Richtung hat, wird mit _drei_ ways gezeichnet. b) Der mittlere way ist der Datenway, auf ihm werden alle Tags untergebracht, die für die _gesamte_ way-Gruppe gelten, wie z.B. highway= secondary, name=Bündelstraße, ref=B 19. als auch die Relationen-Teilnahme, die für alle ways des Bündel gelten. c) auf den ways links und rechts werden nur die tags untergebracht, die für die jeweilige Richtung gelten, z.B. maxspeed=50 und gegenüber auf dem anderen way maxspeed=40 d) Der mittlere way entspricht der derzeitigen Umsetzung für die mittlere Geographische Lage für ways. Er sollte möglichst die Mitte der Straße darstellen. e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. 6. Nun zum Rendern und der Darstellung in JOSM: a) exisitert nur ein way, wird verfahren, wie bisher auch, um die Abwärtskompatibilität zum aktuellen Datenbestand zu erhalten b) _gleichzeitig mit der Einführung des datenway_ sollte es jedoch auch möglich sein, einen 3er-way für eine normale Straße mit einer Fahrspur je Seite zu zeichnen, _ohne dass extra tags auf den äußeren, eigentlichen Fahrspuren untergebracht werden müssten. Das wird nötig, um die Straßenbreite richtig im Renderer Darszustellen. (Weiter unten mehr dazu.) Hier müsste es so aussehen, das automatisch die Abstände für die ways von JOSM vergeben werden können, sprich in welchem Abstand diese in JOSM zueinander stehen. Diese Abbstände könnte man in JOSM als Profil für jede Straßenart festlegen, was den gesetzlichen Vorgabender jeweiligen Fahrspurbreite entspräche. Für andere Länder muss man das entsprechende Landesprofil laden oder festlegen. Auf diese Weise könnten Straßenbreiten festgelegt werden, die der Renderer direkt abbildet. c) jeder fahrspur-way in JOSM bedeutet die Mitte der jeweiligen Fahrspur, so wie jetzt auch die Mitte der gesamten Straße. Der Renderer kann nun je nach Zoomstufe die absolute Lage der einzelnen ways interpretieren und auch die Außenkanten einfach ermitteln und daraus ein Gesamtbild der Straße inkl. Trennstrichen in höchster Zoomstufe oder einer Lupenfunktion für einen begrenzten Bereich zeichnen. d) Weniger fortschrittliche Renderer nutzen einfach den datenway, analog zum derzeitigen Einzelway. Brücken, Abzweigungen einzelner Fahrspuren werden genauso gezeichnet, wie bisher auch. e) um es in JOSM zu erleichtern, sollte der datenway zwischen dem echten Abstand des linken und rechten Richtungsway liegen, da er ja keine eigene Fahrspur darstellt. In größeren Zoomstufen in JOSM sollte dann nur noch der datenway sichtbar sein, wie die derzeitigen ways auch. 7. Brücken mit unterschiedlichen highway/railway-Arten: Analog zur Gruppierung von Fahrspuren könnte man auch eine Gruppierung für ganze Straßen angeben, um Brücken darstellen zu können. Dazu müsste man mehrere datenways zu einer Brückengruppe zusammenfassen können. Gezeichnet wird es dann mit einer gemeinsamen Hintergrundfarbe im Renderer, sodass Brücken nicht mehr "durchsichtig" sind, wenn der highway noch von zwei cycleway und einem railway begleitet wird. 8. Fahrbahnbegleitende Radwege, etc. werden nach wie vor am highway getaggt, nun jedoch auf der jeweiligen Fahrspur für die jeweilige Richtung. 9. Parkstände entlang von Fahrspuren: Auch parking:lane ist nun klar, und muss nicht mehr mit right/ left getaggt werden, sondern einfach auf der Fahrspur, die es betrifft. 10. abzweigende Fahrspur: Wenn sich eine Straße in zwei Fahrspuren teilt, kann nun einfach diese Fahrspur mit der der anderen Straße oder einer Einfädelspur mit einem knoten verbunden werden. Ebenso kann man aus einem Knoten auc zwei Fahrspuren entspringen lassen, wenn sich die Fahrspur für unterschiedliche Richtungen aufteilt. 11. Kreuzungen: Durch das Fahrspur-Zeichnen wird es nun endlich möglich, Fahrspuren so einzuzeichnen, wie sie tatsächlich abzweigen. Kreuzungsstellen der einzelnen Fahrspuren sind normal zu interpretieren. Dort, wo sich eine Fahrspur mit einer anderen Kreuzt, dort gibts einen gemeinsamen node. Abbiegeregeln können sehr einfach über Relationen auf der Fahrspur, wie bisher auch am way abgebildet werden. 12. durchgezogene Mittellinie: Wenn sich so eine auf der Straße befindet kann die nun auf dem datenway einfach getaggt werden. Router wissen dann, dass sie an diesen Stellen nicht von einer Fahrspur auf die andere Fahrtrichtungsseite wechseln dürfen. Analog dazu könnte eine solid_line auch auf einer Fahrspur bei mehreren der gleichen Richtung getaggt werden. Hier muss nur festgelegt werden, ob das immer links von dieser oder rechts von dieser Fahrspur gilt (einziger Pferdefuß, aber derzeit gibt es mehrere, die dieses Konzept lösen würde ;-) So weiss dann jeder Router, ob er einen Fahrspurwechsel vornehmen darf oder nicht (wenn man das denn unbedingt taggen möchte, wäre das nun möglich) 13. Bauliche Trennung: wie bisher werden zwei ways gezeichnet, die nicht gruppiert werden, also keine gemeinsame Signatur/ID erhalten. Diese ways können natürlich mit anderen Fahrspuren einer Gruppe mit nodes verbunden werden. 14. mit dem Fahrspuren wären nun auch Abbiege- und Autobahnauffahrt/Abfahrtspuren gut einzuzeichnen, wenn man das möchte, wenn es der Plausibilität dient. 15. etc. etc. etc. Ich habe sicher noch nicht an alles gedacht, deshalb kein Anspruch auf Vollständigkeit! ;-) Vorteile: ----------- -> die Abwärtskompatibilität bliebe gewahrt -> dennoch stufenweiser Ausbau auf das neue System möglich, ohne die bestehenden Renderer zu stören -> viele Probleme durch umständliches "Ketten-Tagging" für fahrtrichtungsabhängige Tags wären vom Tisch -> viele Relationen wären unnötig. Sie würden nur noch für z.B. Radwanderwege u.ä. weiterhin sinnvoll, so wie vom Erfinder gedacht. Sie würden auch nur noch dort eingesetzt, wo es nicht mehr anders geht. -> Neuuserkompatibilität. Einarbeitungszeit gering, wenn das Konzept erstmal verstanden wurde. Es ist aber in sich logisch und so dürfte die Einarbeitungszeit ungleich kürzer sein, als bisher. -> Fahrspurentagging möglich wo nötig, aber nicht zwingend erforderlich. -> Router könnten out-of-the-box einen Fahrspurassistenten bieten. -> es wäre automatisch klar, wo man Ampel-nodes unterbringen kann, Überquerungen aller Art, Haltestellen zwischen Fahrspuren -> Erleichterung für die Fußgänger-, Fahrradfahrer- und barrierefreien und Blinden-Navigation, da auch andere Wegarten eigene "Fahrspuren bekommen könnten und so getrennt getaggt werden könnten -> usw. Nachteile: ------------- -> sicher gibt es welche, wie z.B. das erhöhte Datenaufkommen -> "jemand" müsste das in die DB einbauen und auch stufenweise in die populären Editoren. -> schon einzelne Tags führen zu Tagelangen Diskussionen. Meint ihr, "wir" die OSM-Community könnten dennoch sowas umsetzen? -> Das Wiki müsste nach und nach an die neue Situation angepasst werden. -> usw. Beachtet, dass das Konzept nicht vorsieht, andere Wegarten zu gruppieren, sondern nur jeweils Fahrspuren innerhalb einer Wegart. Es kann also kein cycleway-Spur zusammen mit den highway-Fahrspuren gruppiert werden. Radwege werden nach wie vor an der äußersten Fahrspur getaggt, wie bisher auch - nur ohne dann unnötige Richtungsangabe. Vielen Dank, an alle, die bis hier gelesen haben. Für die anderen: Bevor Ihr urteilt, lest es bitte komplett, da die eine Frage vielleicht schon weiter unten beantwortet wird. Bitte macht mich gerne auf Denkfehler aufmerksam ;-) Grüße, steffterra _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
