Dito, hab schon 2 kleine Changesets weggeschmissen, weil ich dachte, dass das Prob bei mir wäre.
Scheint wieder zu gehen, Sachsen und Sachsen-Anhalt fertig, bis auf:
https://www.openstreetmap.org/way/239040625#map=17/51.88434/12.39696
Da is das Tagging definitiv falsch, aber auf Bing auch nicht ganz eindeutig zu erkennen und Mappillary hat schöne Fotos von Wolken.
Ich tendiere dazu, das nach none|none|none|merge_to_left* umzuschreiben, weil es mir von der Strassenführung am logischsten erscheint. Irgendwelche Meinungen dazu?
- Die Auffahrt endet irgendwann in einem Standstreifen
Da wo die durchgezogene Linie des Standstrifens beginnt, endet der (typ. 250 m lange) Beschleunigungsstreifen. Habe die turn:lanes ab dort entfernt.
Franz
Das is, was ich mit logisch meinte, aber es ist weder ein Schild zu sehen, noch is was auf der Strasse. Theoretisch könnte ich da ohne nach STVO belangt zu werden etliche km auf der Standspur fahren (Gewiss machen das da bestimmt auch Leute…)
Auf dem Luftbild von Bing ist auch zu sehen, dass der Standstreifen etwas schmaler ist, als die Beschleunigungs- und Verzögerungsspuren. An der nächsten Auf/Abfahrt Richtunr Nord-Osten (Nr7, Köselitz) sieht es auch so aus, dass die schräge Linie (sollen zwei Parabel-Äste sein), die den Beginn/das Ende des Standstreifens anzeigen noch nicht auf die Straße gemalt wurden. Die Auf/Abfahrten Nr. 6 und 9 haben wieder diese Parabel-Äste.
Wenn man bei Bing genau hin sieht, ist dort eine graue Linie zu sehen.
Franz
um bei Mapillary das ganze zoombare Bild zu sehen muß ich die Seite einmal neuladen.
Vieleicht hilft das bei dir auch.
Das ging ja mal schnell, alles aufgeräumt… nur noch ein paar false-positives von proposed-Tags.
Dann können wir direkt weitermachen mit den motorway_links und trunks: http://overpass-turbo.eu/s/6YC
(Die Abfrage für ganz Deutschland braucht sehr lange, deswegen besser nur nach Bundesländern suchen)
Ich bin kein Freund des Todschlag-Arguments "Das war schon immer so*. Historisch gewachsen war auch, dass unsere Urahnen in Höhlen wohnten…
Was hindert uns daran, eine unbefriedigende Situation zu verbessern? Heute Nacht träumte ich von einem lanes-Erfassungstool, das etwa so funktionieren könnte:
-Zuerst erfasst man die Anzahl der lanes und ob der way oneway=yes ist.
-Abhängig vom oneway fordert das Tool die Angabe der lanes:forward und berechnet lanes:backward.
-Darauf aufbauend klappt ein Menu auf, in dem auf Basis der Anzahl von lanes:forward/backward für jede *:lanes-Variante eine Zeile besteht, in denen man dann pro Spur von links nach rechts in way-Richtung ein Auswahlfeld mit den möglichen values hat. Bei destination:lanes können da abhängig von den Richtungsangaben unter turn:lanes die Ortsangaben gemacht werden.
Das Ganze funktioniert aber nur, wenn bei lanes und turn:lanes alle Spuren und nicht nur die für den motorisierten Verkehr angegeben werden. Die Sache wäre auch ohne tool nachvollziehbar und erfassbar. Fehler würden vermieden und wären leicht auffindbar. Insbesondere die innerörtliche Spurerfassung würde vereinfacht und könnte international gepusht werden.
Hat jemand eine Vorschlag, wie so etwas machbar wäre, wenn wir bei der Anzahl von lanes=* bei denen nur für motoriserten Verkehr belassen?
Ich weiß nicht, ob es nicht sinniger wäre, alle Spuren auf der Straße einzubeziehen. Also z.B. auch Fahrradspuren.
Bei Turn:lanes, Access fallen sie doch auch mit rein.
Jep, tatsächlich, danke.
Mein Vorschlag basiert darauf dass :lanes “nur” Spuren für Fahrräder und sonstigen nicht-motorisierten Verkehr ergänzt. Man fragt lanes standardmäßig ab und fragt dann ob noch was dazu kommt.
- Dein Assistent sollte die herkömmlichen lanes für “motorisierten Verkehr breiter als ein Motorrad” abfragen.
- Dann die Frage “gibt es Spuren für Fahrräder oder weiteren nicht-motorisierten Verkehr?” Wenn ja wie viele Spuren sind es damit insgesamt?
- Dann bietet basierend auf der Gesamtzahl Spuren Eingabefelder für alle :lanes an die mit forward/backward und dann mit access/bicycle/psv gefüllt werden. Aus access kann eine Logik dann die herkömmlichen lanes:(forward/backward) bestimmen.
- a) Basierend auf forward/backward setzt er oneway. Dies lässt sich auch manuell ändern.
b) Wenn oneway gesetzt ist fragt er noch ob Fahrräder oder sonstige entgegen fahren dürfen (oneway:bicycle/psv …) - Er fragt auch maxspeed ab, mit Option dies richtungs- oder spurgenau anzugeben.
- Jetzt fragt er turn/destination und weitere gängige :lanes ab.
Danke, ich übernehme das mal in mein Lastenheft.
Aber bevor das Tool entwickelt wird, müssen wir eine Mehrheit für oder gegen die Vorgabe “lanes nennt die Anzahl der für den mehrspurigen motorisierten Verkehr bestimmten Spuren” finden.
+1 für lanes in der alten Bedeutung. Eine Änderung eines eingeführten Tags mit millionenfacher Verwendung ist Unsinn.
Genau genommen fallen bei lanes=* ja nur cycleway:lanes aus der Zählung. Parkstreifen bleiben ja generell unberücksichtigt. Von daher kann man das in einem Tool wohl so durchziehen:
- Anzahl der lanes für motorisierte Fahrzeuge incl. PGV und HGV sowie oneway abfragen.
- Wenn kein oneway, lanes:forward/backward abfragen.
- Anzahl cycleway:lanes abfragen.
4ff) Weitere *:lanes mit Auswahl-Vorgaben abfragen…
Unsinn ist ein bisschen hart, aber ich fürchte auch, dass zu viele Anwendungen einfach die lanes= hernehmen, um die Bedeutung einer Straße abzuschätzen. Da landet eine schmale Straße mit zwei Fahradspuren plötzlich in der Kategorie Hauptverbindung. Sicher, es gibt weitere Tags (width etc), die da genauere Aussagen ermöglichen, aber die müssen a) gemappt worden sein, b) ausgewertet werden. Bei beidem bin ich etwas skeptisch.
Da lieber in den saueren Apfel beißen und unterschiedliche Zählungen zulassen. In OSM gibt es leider viele Räder, die sich wohl nicht mehr zurück drehen lassen.
Aber das spricht ja genau gegen die derzeitige Verwendung. Wenn man jetzt eine Strasse mit 2 lanes für Autos hat, und 2 für Radfahrer, dann wird derzeit daraus eine 4 spurige Straße.
Allerdings glaube ich eher, dass niemand lanes bei Routenberechnungen hernimmt. Für Straßenkategorien haben wir andere tags.
Lanes dient imho nur für kosmetische Zwecke, sei es bei Darstellung von Wegweisern oder auf 3D-Karten.
PS. Ich bringe nochmal meinen Einwand ein (da er so schön ignoriert wurde 
), dass z.B. Fahrradspuren auf der Strasse miteinbezogen werden sollten. Die Fahrbahnmarkierungen sind ja für die Spur auch vorhanden, und so wäre es mit access:lanes und turn:lanes konform.
Das mit dem Aufräumen an motorways und trunks geht ja ganz schön fix hier. Noch 43 Fälle an motorway_links und trunks, an denen potentiell zuviele Spuren in den :lanes tags auftauchen.
Die schlechte Nachricht für euch: Inzwischen findet meine Suche auch die Fälle, bei denen zu wenige Spuren in den :lanes auftauchen. Das macht dann zusammen noch 122 mögliche Fehler an motorways und -links deutschlandweit.
http://overpass-turbo.eu/s/6ZJ
Wer von euch spricht fließend Regex? 
[~".+:lanes$"~"(^[^\\|]*\\|?[^\\|]*\\|?[^\\|]*\\|?[^\\|]*\\|?[^\\|]*$|\\|.*\\|.*\\|.*\\|.*\\|.*\\|)"]
Auf längere Sicht werde ich versuchen, diese Checks in Keepright einzubauen, aber das wird etwas dauern - vorher gibt es noch andere Probleme zu lösen.
+1
Edit: ich hab ma im Wiki ein paar Overpass-QA-Links gesammelt aus diesem Thread: https://wiki.openstreetmap.org/wiki/User:Dex2000#Overpass-turbo-abfragen_f.C3.BCr_turn:lanes-Fehler_und_wahrscheinliche_Fehler
Wenn ich was übersehen hab…
Bin ich zu alt für, aber aus meiner Erfahrung mit diversen Codes als interessierter Laie: sieht sehr schön aus 
Edit. Ich wette, das kann man noch einkürzen 
/edit
Hat nur 'nen Haken, wie man bei proposed:lanes schon gemerkt hat; es holt leider - soweit ich das auf die schnelle überblicke zuviele false positive. In Hessen hab ich mir das grad mal grob angeschaut und da frisst das* leider source:lanes, note:lanes und dergleichen mit.
- Das=der overpass-link
Das habe ich schon versucht zu eliminieren, allerdings scheint unsere API keine (negativen) Lookaheads in regular expressions zu kennen. Vielleicht hat jemand eine Idee wie man das hinbiegt?