Im Rahmen der Wochenaufgabe turn:lanes bin ich auf den Schlüssel lane=* gestoßen.
Dieser way war der Aufhänger für meine Recherchen.
overpass zeigt die Verwendung folgendermaßen weltweit .
In der Wiki kann ich nichts zu diesem Schlüssel finden. Stutzig machen mich auch parallele Erfassungen zu highway=* mit lanes=* sowie die verwendeten values.
Wie sollen wir damit umgehen?
Die B 170 lief hier mal über diese Spuren.
Es hat sich halt noch niemand getraut das zu löschen
Das mag ja in diesem Einzelfall (inclusive benachbarte Fälle) zutreffen. Aber speziell da muss sich doch jemand beim ändern von highway=* in lane=* was gedacht haben 
Womit das weltweite Erfassen aber nicht plausibel wird.
Ich habe mal in der weiteren Umgebung nachgesehen. Da waren das alles Flüchtigkeitsfehler oder originelleTaggings:
z.B. lane=1 statt lanes=1 oder highway=lane + lane=path.
Das sieht mir eher nach Aufräumen als nach verborgenem Sinn aus.
Na denn:
Wir gründen das OSM-WWWDT? (OpenStreetMap-WorldWideWasteDisposalTeam)
Ich weiß, du sprichst von mir. Und ich kann auch damit leben, die über PN mit dir geführte (und leider bisher ergebnislose) Diskussion dazu hier vor Publikum weiter zu führen. Dabei bin ich gespannt, wie die Allgemeinheit dazu auch im Bezug auf deine Beispiele steht.
Ich habe in der Ecke seinerzeit nach Bing das lanes-Schema umgesetzt. (Nach dem zugrunde liegenden thread suche ich jetzt nicht.) Es steht jedem frei, dort nach Ortskenntnis bei Erfordernis über relation=restriction oder sonst etwas Etabliertem die erforderlichen Änderungen zu erfassen. Sollte ich valide Hinweise dazu bekommen, bin ich gerne bereit, dies zu übernehmen. Ich sehe da auf den ersten Blick keinen Fall, der sich nicht mit etablierten Methoden lösen ließe.
OK, diese Idee eines lane-Tagging kann ich nachvollziehen. In der zunehmenden Tendenz zu Detail-Mapping würde ich nicht ausschließen, dass das einmal kommt. Bei den Gehwegen wird das getrennte Mappen inzwischen ja teilweise schon praktiziert.
Bei Straßen wäre das aber eine völlige Umkrempelung des bisher geübten Verfahrens, eine Koexistenz dürfte schwierig sein.
Manches würde einfacher, aber dafür tun sich andere Probleme auf: Wie sollen zusammengehörende Spuren zusammengefasst werden? Wie soll Spurwechsel abgebildet werden?
An Relationen führt da mMn kein Weg vorbei, da kommt bestimmt Freude auf.
Auf komplizierte Fragen gibt es halt leider keine einfachen Antworten.
Aber zum vorliegenden Problem: Die Fälle, die ich gefunden habe, ordne ich unter Mapping-Unfälle ein. Bis auf die lane(s)=n muss man sich die aber alle einzeln vornehmen. Meine Devise: bei Gelegenheit. Ich versuche für mich eine Balance zwischen QA (waste disposal, Irre, …) und Neuerfassung zu halten.
Ich bin dann mal weg (nur virtuell).
Ohne Links zu OSM und ohne Ortskenntnis kann man sich da schlecht die OSM-Daten rausfuddeln. (ok, 2 Klicks weiter…)
Hab ich mal trotzdem stichprobenartig gemacht, kaum wirklich Probleme gefunden. Mal als Beispiel:
https://graphhopper.com/maps/?point=50.902925%2C13.681347&point=50.904988%2C13.686304&vehicle=bike&locale=de-de&elevation=true&layer=Lyrk
Hier rechnet - soweit ich das sehe - tatsächlich Graphhopper falsch, da könnte denen mal wer ne mail schreiben, wen’s stört …
Falsch gemappt is das nich. Man könnte jetzt auf Verdacht für den Renderer mappen und statt straight_on ein no-right-dingens dranpappen, is aber eigentlich nicht unser Problem, und oben kann er das komischerweise noch oder überseh ich da was?
Edit: Scheinbar überseh ich da nix, http://osrm.at/aeo macht es genau so, wie ich es erwarten würde, oder bekommt jemand das ziel auf den gesperrten Feldweg gezogen? Ich nich.
Edit²: Ich bin jetzt alle 9 Beispiele durchgegangen, bis auf mein obiges Beispiel sieht alles (wenn man mal Nummer 9 (taggen für den Renderer) weglässt) korrekt aus.
Ist bekannt, dass Hopper keine TurnRestrictions kann.
War mir bisher unbekannt. Und offensichtlich bei der Suche nach Negativbeispielen zur Auswertung von turn:lanes auch 
Gibt es eigentlich irgendwo etwas, woraus man erkennen kann, was einzelne Router auf OSM-Basis leisten können?
@hurdygurdyman: Es bezieht sich nicht auf unsere persönliche Diskussion - es bezieht sich auf die Aussage: “Weltweites Entsorgungsteam”
Da war es nach dem alten Festlegungen getrennte hw mit Doppellinie gemappt.
Beispiel 1 - http://graphhopper.com/maps/?point=50.902925%2C13.681347&point=50.904988%2C13.686304&locale=de-de&layer=Lyrk - einfach einmal BING darunter - es sind Doppellinie über die dei angeblich richtiges Routing führt.
Beispiel 2 - dito es müsste über den Abzweig in Oberhäslich geroutet werden
Beispiel 3 - dito müsste über Alte Altenberger Straße routen
…
Ich habe nichts gegen das lanes-Schema, aber es kann nicht alles abdecken. Wenn an einen hw ein lanes=2 hängt ist es auch i.O. Aber schon wenn Radspur, Busspur, Rechtsabbieger, Geradeausfahrer, Linksabbieger auf einen hw liegen und das noch einmal in Gegenrichtung mit mittig liegender Straßenbahn …
Mittlerweile wird immer detaillierter gemappt, was ich als Riesenvorteil (Vorsprung) gegenüber anderen empfinde. In Autoatlanten wurden komplizierte Kreuzungen als Detailabbildung eingefügt … (Ich hatte damals die Spuren als einzelne hw, was falsch war, es hätte ein hw mit lanes=2 sein müssen, zumindest dort wo 2 lanes in gleicher Richtung verlaufen. Aber da galt auch eine Doppellinie noch als bauliche Trennung.)
https://wiki.openstreetmap.org/wiki/Routing/OnlineRouters
Komische Geschichte, ich könnte schwören vorhin war in dem Beispiel Start und Ziel verbunden. Was sie nun korrekt nach OSM-Daten nicht sind. Mit “oben” meinte ich die obere “Einfahrt”. Auf deutsch: Graphhopper routet das korrekt nach Plan nicht, zeigt aber den Zielpunkt (oder eben Startpunkt) an.
Wäre schön, wenn man zur Wahrheitsfindung erstmal bei genau diesem einem Beispiel bliebe, ich raffs nämlich immer noch nicht; was genau ist an diesem Routing falsch:
?
Edit: Herrje, die Konfusion mit den verbundenen Start- und Zielpunkten kam daher, dass ich irgendwie Bike aktiv hatte. Ändert allerdings nix an der Frage: mit dem Auto kommt man da nich rein, und graphhopper zeigts korrekt an.
Ich würde mal sagen, GraphHopper verarbeitet fürs Routing schlicht und ergreifend kein highway=track. Darum nimmt er die nächstgelegene Straße an… Dann ist das Routing wieder korrekt…
denkt sich Sven
Nachtrag: MapQuest bietet anscheinend eine funktionierende Lösung an.
Schau bitte einmal auf BING - das kann nicht gehen.
Ich weiß schon, was du meinst…
Doch… Versuche mal auf ein der Waldwege im Wald nördlich von Oberhäslich ein Ziel zu setzen… geht nicht… GraphHopper kennt fürs Routing kein highway=track und der Startweg in deinem Beispiel ist ein highway=track. Da Graphhopper keine Track kennt , nimmt er die nächstgelegene Straße. Graphhopper kann aber nicht wissen, daß du von dem Nebenweg kommst. Also ist es korrekt, im Sinne der Daten, die er fürs Routing hat.
Anscheinend beachtet Mapquest aber auch nicht sie Abbiegebeschänkungen richtig… gerade gesehen.
Mittlerweile sind wir hier vollkommen OT.
Alles, was ab meiner Frage zur Gründung des weltweiten Müllentsorgungsteams folgt, gehört nicht mehr zur Ursprungsfrage nach dem key lane=*.
Sucht mal nach Spurmapping im Forum, dort gehört das eher rein. Ob das aber zu einem Ergebnis oder sogar Konsens führt, wage ich zu bezweifeln.
Ja, und er hat seit damals nochmal gedacht und von ihm aus kann es gerne weg. Ist nur die Frage wie lokale Mapper das sehen 
Mir auch.
Ich hab da heute Abend übrigens schon paar Dinge, die mir eindeutig erschienen elimi-gelöscht - ääh - korrigiert.