Die Ursache liegt darin, dass diese Straße als trunk getaggt ist, obwohl sie baulich nicht die Bedingungen erfüllt.
Laut den Bayern-Luftbildern ist sie durchgehend ohne Fahrbahntrennung.
Die AIO, und wahrscheinlich andere Stile, fügen zu highway=trunk aber oneway=yes hinzu, wohl um Geisterfahrer zu vermeiden,
deswegen kommt dann nicht auf die B12.
Da ich nicht ausreichend ortskundig bin möchte ich diese Straße nicht ohne Diskussion ändern.
Wenn solche Straßen richtig getaggt sind, findet man keine getrennten Fahrspuren ohne oneway=yes. In OSM gibt es ja zum Glück keine Fehler.
Die B12 in dem Bereich ist nur mit Trennlinie und wechselnden 2+1-Spuren versehen, ist ein typischer Fall wo zwei Mapper drei verschidenen Meinungen haben.
Ich werde mein Problem wohl auf meiner Seite lösen müssen
Echte bauliche Trennung ist das nicht, trotzdem wird 2+1 System gerne als Dual-Carriageway gemappt.
Das oneway=yes darf dabei natürlich nur bei letzterem gesetzt werden.
Wie schon gesagt, wahrscheinlich/ziemlich sicher, habe ich einen Fehler gemacht, den kann ich ja leicht korrigieren.
Eine Diskussion über primary vs. trunk will ich nicht angestoßen haben.
Wegen dem implizierten oneway=yes gibt es für motorway, motorway_link und trunk das Tagg oneway=no. Ist leider oft nicht erfasst, aber sollte beim Rendern beachtet werden. Diese Situation gibt es bei Auf- + Abfahrten sogar recht häufig.
Weiter sollte bedacht werden, dass in DE eine doppelte Mittellinie als bauliche Trennung gilt.
Edit: Der komplette Trunk ist ohne oneway-Tagg. Dabei wird der Unterschied zwischen oneway=yes und oneway=no im Verlauf dieses Trunks leider unterschlagen.
‘highway=trunk’ implementiert lt. Wiki kein oneway=yes, man muss es explizit setzen.
‘oneway=no’ ist auch nur dort nötig, wo ein ansonsten vorausgesetztes ‘oneway=yes’ (IMHO nur bei motorway, motorway_link) aufgehoben werden muß, z.B. Ausfahrten.
Edit: Chris66 hat gerade so einen Fall in diesem Weg http://www.openstreetmap.org/browse/way/166825386 gefunden
Mein Fehler war nur eine verkorkste Regel, die ich aber mittlerweile korrigiert habe, das Routing über die genannte Stelle klappt wieder.
wenn highway=motorway immer auch oneway=yes impliziert, könnten wir noch in einzelnen Baustellenbereichen Routingprobleme haben, nämlich dort wo der Verkehr über einen Way geführt wird, jedoch kein oneway=* eingetragen wurde. Hier eine kleine Auswertung für DE. Die 29 Einträge sollten relativ schnell zu prüfen und korrigieren sein.
Prima! Die fehlenden oneway=* Tags an den motorway_links scheinen doch das größere Problem zu sein. Soweit ich das stichprobenhaft überblicken kann sind in der zweiten Liste einige vergleichbare Fälle drin, z.B. http://osrm.at/1BP … Das einzelne oneway=-1 hängt wohl mit dem Alter der lokalen Datenbank zusammen (1 Woche, wird gerade aktualisiert).
Zu den “Edit-Wars” mit oneway=no löschen bei motorway_links: Hier müsste im Wiki klar dargestellt werden, dass oneway=* verpflichtend gesetzt werden muss. Im Gegensatz zum englischen Text fehlt in der deutschen Version übrigens jeglicher Hinweis auf oneway=*.
Außerdem waren in der Deutschen Version Motorräder gesperrt (Impliziert: access=no, motorcar=yes).
In den restlichen Sprachen ist dieser Fehler noch drin.
Eigentlich muss ich Michael hier zustimmen. Die Implikation oneway=yes für motorway_links halte ich auch für Käse. Implikationen mögen nützlich sein. Aber nur wenn sie mehr nutzen als schaden.
Ich verstehe nicht soviel von Java, aber ich kann nirgendwo im Code von mkgmap finden, wo ein motorway_link automatisch ein oneway=yes bekommt, einzig in den Defaultstyles von mkgmap befindet sich { add oneway=yes …} bei einem motorway_link. Wenn also jemand dieses benutzt, dürfte das Problem bestehen, ansonsten nicht.
Und bei der Menge von rund 50 Ausfahrten, die allein in meinem DACH-Poly bei dem von Chris genannten Check ‘26217018: motorway_link lacks oneway’ gefunden werden, sollte das öfters zu Routingproblemen führen. Sprich, es wäre irgendwann hier erwähnt worden.