Routing / Spurmapping

ohne das jetzt vor ort zu kennen, kann das doch durchaus sinn machen? je nachdem wo eben u-turn/abbiegeverbote sind.

//edit: wobei diese route wirklich toll ist :slight_smile:
http://maps.google.de/maps?saddr=Werftstra%C3%9Fe%2FL52&daddr=54.3180137,10.1552064+to:Unbekannte+Stra%C3%9Fe&hl=de&ie=UTF8&ll=54.31601,10.151249&spn=0.00485,0.00883&sll=54.316284,10.151295&sspn=0.001213,0.002207&geocode=FZDMPAMdM-eaAA%3BFb3TPAMdxvSaAClD3cMAVFayRzH7KxWDSX5X5w%3BFbnNPAMdnuSaAA&mra=ls&via=1&t=h&z=17

Ich kennen es vor Ort, und das macht ueberhaupt keinen Sinn. Das kann man uebrigens auch in der Luftbildansicht klar erkennen, wenn man ordentlich rein zoomt. Die Verwendung von getrennten Wegen ist an dieser Stelle voellig unnoetig und offensichtlich alles andere als hilfreich.

In diesem speziellen Fall ist die von Google bestimmte Route uebrigens nicht nur ein fuerchterlicher Umweg, zusaetzlich fuehrt sie auch noch ueber Wege, die der Oeffentlichkeit gar nicht zugaenglich sind und zwar ueber das Marinearsenal.

Ja, die ist noch schoener. Die andere hatte ich gestern leider am eigenen Leib erfahren muessen, als mich ein Android-Handy da hin lotsen sollte.

Gruss
Torsten

Für wie wichtig erachtet ihr das Abbilden der eigentlichen Strasse, sprich der geschlossenen Fahrbahndecke?

Zur Erklärung:

Eine Durchgangsstrasse geht durch einen Ort. Sie hat praktisch durchgehend die gleiche Breite. Lediglich die Markierung ändert sich.
Zunächst hat sie je eine Spur für beide Richtungen und rechts sind Parkplätze auf der Strasse markiert.
Dann enden die Parkplätze, die Vorwärtspur verschwenkt nach rechts und macht Platz für eine Verkehrsinsel in der Mitte.
Nach der Insel verschwenkt die Spur wieder zur Mitte und rechts sind wieder Parkbuchten.
Am Ende enden die Parkbuchten, die Geradeausspur schwenkt nach rechts und in der Mitte entsteht eine Linksabbiegerspur.
An allen Stellen hat die Strasse an sich die gleiche Breite.

Warum ich das als wichtig erachte?

Zum einen gibt es vielleicht mal einen Import amtlicher Daten, dort ist u.U. nur die Strasse(nbreite) angegeben, aber nicht die Markierung.
Ausserdem werden Ummarkierungen schneller mal gemacht, als die geschlossene Fahrbahndecke zu verändern.

Und zum anderen, wenn ich diese Strasse tagge, und die ist in der Realität schnurgerade, und ich gebe meine oben genannten Spuren an, wird sie wohl Schlangenlinien machen.

Das bringt mich wieder zu meinem Gedanken, nur die geschlossene Fahrbahndecke im Lanes-Tag zu beschreiben, und Fuss- und Radweg in den vorhandenen eigenen Tags (die dafür evt. noch erweitert werden müssten), aber im Way, zu belassen.

Ein Nachteil: Parkbuchten rechts auf der Strasse müsste ich woanders angeben als die links neben der Strasse.

Dann berichte ich mal:
Die Installation des plugins war vollkommen problemlos über das in JOSM integrierte tool.
Ich habe mir bewusst erst einmal einen Bereich ausgesucht, in dem jeweils nur eine Abbiegespur vorhanden ist. Es handelt sich um diese kreuzungsfreie Auf-/Abfahrt
http://www.openstreetmap.org/?lat=48.334078&lon=7.826449&zoom=18&layers=M
Folgende Abbiegevorgänge wurden bearbeitet:

  1. http://www.openstreetmap.org/browse/node/258045671
  2. http://www.openstreetmap.org/browse/node/258045658
  3. http://www.openstreetmap.org/browse/node/265549774

Leider ist bing hier nicht sehr hoch aufgelöst, sodass ich erst einmal vor Ort (bei der Saukälte) die ungefähre Länge der Abbiegespuren anhand markanter Punkte ermitteln musste. Hierzu habe ich einen Bildschirmausdruck verwendet. (Für eine komplexere Kreuzung, die ich als nächstes angehe, habe ich mir schon einen Ausdruck mit WalkingPapers gemacht. Da werde ich dann die Längen abschreiten oder die Steine der einen Meter langen Bordsteinkanten zählen.)

Nach Anklicken des Abbiegepunktes fordert das plugin grundsätzlich, die Anzahl der lanes für alle sich dort treffenden ways anzugeben. Bei (z.B. wegen einer Brücke) gesplitteten ways, auf denen eine längere Abbiegespur verläuft, muss dies für alle betroffenen ways erfolgen. Danach erscheint dann die zu bearbeitende Kreuzung im Plugin-Fenster und man kann mit dem Zeichnen der Abbiegespuren und dann mit den Verbindungen zwischen den Spuren beginnen. Das ist einfach und intuitiv machbar. Die Relationen entstehen im Hintergrund automatisch. Allerdings meckert JOSM beim Abspeichern, dass es die Relationen „turnlanes:lengths" und „turnlanes:turns" nicht kennt.

Zu 1.
Hier habe ich die zwei restriction–Relationen testweise entfernt, da ja nun identische Informationen als positive Werte vorliegen. Bei 2. und 3. habe ich sie allerdings belassen, um die restriction auswertenden router nicht komplett aus dem Tritt zu bringen. Auf Dauer sollte man aber auf diese Doppelerfassung von Informationen verzichten.

Verwundert hat mich, dass turnlanes an diesem Punkt
http://www.openstreetmap.org/browse/node/259716674
und diesem
http://www.openstreetmap.org/browse/node/262197688
nicht „ansprang". Auch hier gibt es Abbiegespuren :confused:

Ob es Möglichkeiten gibt, das Plugin auf Linksverkehr umzustellen, ist mir nicht bekannt.

Wünschen würde ich mir noch eine Möglichkeit, über einen weiteren Relationstyp (turnlanes:direction) die Richtungsbezeichnungen z.B. über Autobahnspuren erfassen zu können, wodurch Renderer/Router weitere Details anzeigen könnten.

Mein einziger „Wermutstropfen" ist, dass beim Herauszoomem, um etwa sehr lange Abbiegespuren anzulegen, die Längenbeschriftung zu klein und unlesbar wird.

Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.

P.S.:
Einigen wird auffallen, dass bei 1. und 2. die Wege
http://www.openstreetmap.org/browse/way/46821460
und
http://www.openstreetmap.org/browse/way/46518705
eigentlich jeweils als zwei oneways wegen der dazwischen befindlichen Insel anzulegen sind. Ich habe das bewusst erst einmal so belassen, um in einem weiteren Schritt zu prüfen, was bei derartigen späteren Änderungen im turnlanes-plugin zu beachten ist :wink:

Ich habe mir das im Rahmen meiner Spur-Recherchen in meiner Gegend mal genauer angeschaut. Es scheint so , als ob Google die Fahrtrichtungen überwiegend getrennt anlegt, sobald Abbiegespuren vorhanden sind.

Ich fand aber auch einzelne Stellen, an denen dies nicht der Fall ist :confused:
http://maps.google.de/maps?saddr=Werftstra%C3%9Fe%2FL52&daddr=Unbekannte+Stra%C3%9Fe&hl=de&ie=UTF8&ll=48.340726,7.886035&spn=0.001528,0.002411&sll=54.316137,10.151292&sspn=0.001353,0.002441&geocode=FZDMPAMdM-eaAA%3BFdfNPAMdXuSaAA&oq=bremen+seba&mra=mift&mrsp=0&sz=19&t=h&z=19

Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.

Naja, zumindest führt es zu einem klar definierten Ergebnis, dass sich bei einer Entscheidung leicht (halb-)automatisch anpassen ließe. Dagegen kann man nicht jede von irgendjemandem privat beschlossene Variante aufspüren.

Dann sag doch mal, was du von diesem Lösungsansatz hältst. Oder hast du vielleicht sogar einen viel besseren Vorschlag. Für mich ist dieses proposal und plugin erst einmal ein guter Ansatz mit Entwicklungspotential. Was daraus wird, entscheidet die Masse auch durch Akzeptanz.

Nichts. Es deckt nur einen kleinen Teil der Anforderungen ab, benötigt trotzdem Relationen, und Spurlängen in m anzugeben ist albern. Soll man mit dem Maßband auf der Straße herumgehen? Was ist, wenn der Way geteilt wird (z.B. Brücke, Geschwindigkeitsbeschränkung)?

Siehe weiter vorn im Tread. Nochmal der Link: http://wiki.openstreetmap.org/wiki/User:Fkv/lane_mapping_draft.

Ich habe mir die verschiedenen Ansätze in diesem Thread und den verschiedenen Proposals zum Thema genauer angeschaut. Dazu gehört auch deins.

Im Wesentlichen besteht Einigkeit, dass die lanes als Bestandteil der ways abgebildet werden sollen. Es existieren jedoch verschiedene Vorschläge über die Gestaltung der key-value-Paare. Bevorzugt wird nach meiner Beobachtung der Ansatz, welcher die betroffenen lanes mit Trennzeichen dazwischen einem Key entsprechender Eigenschaft zugeordnet.
Dies gilt auch für den Vorschlag von benshu. Zusätzlich werden darin aber Relationen eingesetzt, wodurch erkennbar und auswertbar wird, wie es bei Verwendung der entsprechenden Spur nach dem Kreuzungs- bzw. Abzweigpunkt weitergeht. Außerdem hat dies den Vorteil, dass die lanes unabhängig von der way-Richtung abgebildet sind, was die Konstruktion robust gegen zufällige oder gewollte Drehungen der way-Richtung macht.

Zu deinem Einwand wegen der Spurlängen in Metern vom Kreuzungspunkt aus:
Bei hinreichender Auflösung von bing/Aerowest etc. brauchst du kein Maßband, denn in JOSM kann man messen. Wenn der Weg geteilt ist wie z.B. in meinem Fall 3 http://www.openstreetmap.org/browse/node/265549774 , kann das plugin vom Abbiege-/Kreuzungspunkt rückwärts über mehrere Wegteile arbeiten, sofern diese angaben zu lanes=* haben, was man auch im ersten Video des Proposals gut sieht.

Für mich ist diese anwenderfreundliche Erfassung von Straßenspuren kein „nur kleiner Teil der Anforderungen", auch wenn Radfahrer und Fußgänger noch nicht berücksichtigt sind. Mir stellt sich die Frage, ob es nicht besser ist, ein Tool zu haben mit dem wir zumindest Spuren für motorisierten Verkehr einfach erfassen können, oder ob wir weiter nur von einer eierlegenden Wollmilchsau träumen wollen.

Gerne bin ich bereit, auch andere Lösungsansätze auszuprobieren, wenn sie ein Mindestmaß an Anwenderfreundlichkeit bei der Eingabe erfüllen, was ich leider bei der Masse der vorliegenden Proposals noch nicht erkenne.

Außeerdem bewegen wir uns solange im spekulativen Bereich, wie wir nicht wissen, ob Auswertungen wie Renderer oder Router überhaupt mit diesen Daten etwas vernünftiges anfangen können. Bei einem derartig komplexen Bereich müssen wir dies in unsere Überlegungen einbeziehen.

Ich denke, dass laesst sich mit den verschiedenen Lanes-Vorschlaegen schon ganz gut beschreiben (mit einigen besser, mit anderen weniger). Aber man darf hier nicht aus den Augen verlieren, dass die Lanes in erster Linie eine funktionelle Beschreibung sein sollen. Die koennen und sollen keinen Ersatz fuer das hochaufloesende Luftbildabmalen sein. Umgekehrt kann letzteres aber auch nicht die funktionelle Beschreibung ersetzen.

Mit den Lanes-Vorschlaegen kannst du im Prinzip ja fuer jeden Abschnitt angeben, welche Spuren sich dort befinden, wie breit diese Spuren sind und wie die Trennung zwischen den Spuren aussieht. Der stationaere Zustand ist damit eigentlich hinreichend beschrieben. Beim Uebergang von einem Abschnitt zum anderen sehen die Vorschlaege zwar vor, dass man erfasst, welche Spur vom ersten Abschnitt zu welcher Spur im zweiten Abschnitt fuehrt, daraus wird ein Renderer aber sicherlich kein Pseudo-Luftbild konstruieren koennen.

Gruss
Torsten

Sicher, dass dadurch die Werte richtungsinvariant werden? Eigentlich haengt die Abfolge der Lane-Erfassung immer von der Richtung des Weges ab. (Hast du noch mal einen Link zu benshus Vorschlag?)

Das bestimmt nicht. Aber nur, weil es fuer einen Vorschlag schon mal ein JOSM-Plugin gibt, ist der Vorschlag damit bestimmt nicht automatisch anwenderfreundlicher als andere. Oder soll das hier mal wieder das JOSM-Diktat fuer eine suboptimale Entscheidung sorgen?

Sprach der Mensch, der nicht mal ohne spezielles Eingabe-Tool ueber die Moeglichkeiten der Datenerfassung werten kann :slight_smile:

Scherz beiseite: Niemand wird fuer die verschiedenen Vorschlaege mal eben so einen Beispielrouter mit Spurrouting zaubern. Das gibt es zur Zeit nicht fertig und das wird auch erst irgendwann in der Zukunft entstehen, wenn dafuer geeignete Daten als Grundlage existieren.

Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.

Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.

Aber mal was anderes:
Wie kommen wir bei dem Thema weiter voran? Bisher haben wie nur Ideen und Vorschlaege gesammelt.

Gruss
Torsten

Da muss ich mich nochmal wiederholen: Ich behaupte mal, dass in 90%+ die Verbindung der Spuren eindeutig ist. Vielleicht sogar 95 oder noch mehr. Z.B. wenn die Spuren der Zielstrasse gleich der Ursprungsstrasse sind. Oder wenn 2 Rechtsabbiegerspuren in die beiden rechtesten Spuren der mehrspurigen Zielstrasse münden. Es macht keinen Sinn Relationen zwingend zu erfordern, wenn es nicht nötig ist.
Verbleibt die Minderheit der Kreuzungen, die wohl nicht ohne Relationen auskommen. Z.B. bei Abbiegung rechts und halbrechts.

Wenn ein Router damit nicht umgehen kann, können wir es gleich ganz lassen.

Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes

Sicher nicht. Weiter oben habe ich gesagt:
Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.

Mir gefällt die für diesen Fall bewusst gewählte Rolle als DAU. :wink: http://de.wiktionary.org/wiki/DAU
http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (die ersten drei :slight_smile: )

An der Grundlage arbeiten wir.

Das Thema ist nicht trivial zu lösen. Die Frage für mich ist generell, wie wir - trotz und entgegen dem Mantra - den Spagat zwischen anwenderfreundlicher Erfassung und einem auswertungsfreundlichem Datenschema schaffen.

http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (zweiter Spruch)
Wir haben soviel subopimales in OSM, über das wir hier wiederholt ergebnislos raufen. Ich bin offen für jede überzeugende Alternative.

Das sehe ich auch so, die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
“Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen.” :wink:

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.

Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.

Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.

Ob man die Verbindungen der Spuren von einem Weg zum naechsten besser per Tags oder besser per Relation erfasst, bin ich mir nicht sicher. Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Gruss
Torsten

Neben dem turnlane-plugin gibt es noch zwei weitere, die in den Weiten der Wiki schlummern:
http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts
zeigt einen Ansatz am Beispiel einer kreuzungsfreien Autobahn-Auf-/Abfahrt.
http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
ist ein Versuch, Straßenspuren mit Rad- und Fußwegen unter einen Hut zu bringen.

Auch sie entstanden aus der Erkenntnis, dass mapping von Spuren für den normalen OSM-Mapper nicht ohne Eingabehilfe attraktiv wird bzw. überhaupt umsetzbar ist. Ich habe beide noch nicht getestet und kann sie deshalb auch nicht beurteilen. Aber deshalb muss man die Plugins ja nicht gleich verurteilen. Schließlich haben da Menschen Hirnschmalz und Zeit investiert um OSM voran zu bringen.
Eine Vision wäre, die Vorteile der verschiedenen Erfassungshilfen zu kombinieren, um dann ein anwenderfreundliches Tool für die Erfassung von Spuren bzw. Linienbündeln zu haben, welches die Daten robust und auswertungsfähig speichert.
Hier noch einige weitere links zum Thema:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane
http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_as_Relations
http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry
http://wiki.openstreetmap.org/wiki/Vorschlag_Mittelstreifen_und_Seitenbereiche
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist
Vielleicht bieten die auch noch ein paar gute Ideen :confused:

Aber es wäre doch z.B. hier
http://maps.google.de/maps?saddr=St%C3%BClerstra%C3%9Fe&daddr=Spreeweg&hl=de&ie=UTF8&ll=52.508572,13.350325&spn=0.002563,0.004812&sll=52.508136,13.349888&sspn=0.001282,0.002406&geocode=FYE1IQMdPLHLAA%3BFSpSIQMdz7nLAA&mra=mift&mrsp=0&sz=19&t=h&z=18
hilfreich, wenn ich als Ortsfremder im tosenden Verkehr folgende Ansage bekäme:
„In hundert Metern auf die zweite Spur von links einordnen, dann nach hundert Metern links abbiegen und der zweiten Spur von links geradeaus bis zum Kreisverkehr folgen."

Richtungsabhängige Fahrspuren sind genauso Realität wie footways oder Hundekottütenspender, weshalb deren exklusive Erfassung in OSM durchaus berechtigt ist. Solange Spurwechsel möglich ist, sollten sie aber nicht als eigenständiger way angelegt werden, denn sie sind dann Bestandteil des highway.
Auch dieser thread enthält einige interessante Ansätze zur Problemlösung. Lasst uns doch die „best of" bündeln und daraus etwas Vernünftiges machen.
Unser Problem entsteht auch durch Linienbündel. Da wurde schon vor vier Jahren in einem Workshop dran gearbeitet.
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel
Die Erkenntnisse treffen heute noch zu. Leider sind wir immer noch nicht weiter. Das lanetool-plugin entstand übrigens infolge dieses Workshops.

Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)

Sehe ich nicht so :confused:
Schau dir mal diese Test-Relation an: http://www.openstreetmap.org/browse/relation/2006310
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als “lanes:extra” und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt “via”. Siehe auch http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Allowed_Turns
und im Beispiel http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Example_2 mit einer Rechtsabbiegespur.
Das ganze ist genauso robust wie die turn-restrictions , da from-via-to die Richtung bestimmt.

Hast du einen besseren? Diese Ansatz hat den “Vorteil”, dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind, die zusätzlichen lanes nicht über alle Wegteile anlegen muss, wenn man die Spurlänge will, was aber aus Sicht des routing sinnvoll ist. ich sehe den Vorteil darin, dass man mit Ausnahme der “Standard-lanes” an den beteiligten ways selbst nicht weiter herumbasteln muss.

  • edit: Dreckfuhlerberüchtigung*

Ist zwar neben der “Spur” - aber trifft auch hierzu.

Ich hatte als Neuling vor einem Jahr schon einmal einen Vorschlag zu den vielen, viel zu vielen “Eigenständigkeiten des Taggen”.

Es gibt ein “TEAM”. Besetzt mit den “Urgesteinen von OSM”. Diese treffen nach Diskussionen auch eine “Entscheidung”. Und warum soll eine “Entscheidung” nicht auch noch einmal diskutiert werden, wenn neue Erkenntnisse es erfordern.

Etwas “Demokratie” unter die “Anarchie”.

So wie bei der Lizenzdiskussion? “Sag ja oder verschwinde!”

weissnich,
ajoessen