Hi,
sieht jemand in den Daten Sperrungen, die OSRM dazu bringen, das Gambacher Kreuz zu meiden?
Chris
EDIT: Der graphhopser “geht” korrekt 
interessant…
das geht nicht:
Yepp, ich vermute dass OSRM beim Datenabzug einen Schluckauf hatte.
Oder er hat ein Problem mit den lane-Tags die dort vor 26 Tagen ergänzt wurden.
Liest der Programmierer des OSRM hier mit?
Korrektur: Es wurden lit und surface Tags ergänzt. Daran sollte es also nicht liegen.
Im Bereich Wetzlar scheint auch ein Stück der A45 komplett zu fehlen bei OSRM.
Stimmt das sieht man hier
https://www.openstreetmap.org/#map=16/50.5757/8.5412&layers=H
(manchmal ist es gut wenn Karten nicht so oft gerendert werden 
)
Beim anderen findet man auch was in der nähe…
https://www.openstreetmap.org/note/1884976#map=16/50.4867/8.6925&layers=HN
Ich war gerade bei https://www.openstreetmap.org/way/27287203, auch mit construction=yes. Das kann ein Router schon als „im Bau, nicht nutzbar“ auffassen.
Ich hab die construction=yes mal weggenommen und in https://www.openstreetmap.org/changeset/74156081 einen Takt dazu geschrieben.
–ks
Wilde Vermutung: Bei einer Baustellenverschwenkung ändert der Kollege die stillgelegte Fahrbahn auf construction=yes und die andere, über die beide Fahrtrichtungen laufen, auf construction=no. Wie gesagt, wilde Vermutung. Das wäre natürlich nicht routingfähig, man müsste die befahrene Bahn oneway=no setzen und vorn und hinten geometrische Übergänge mappen.
–ks
http://overpass-turbo.eu/s/MNE
Da nochmal
https://www.openstreetmap.org/way/324045587#map=17/50.48308/8.69763
https://www.openstreetmap.org/way/27287200#map=19/50.58099/8.53960
Vielleicht fällt er über das construction=no drüber… ist ja genauso sinnvoll wie oneway=no 
@chris66: schön wäre noch gewesen, wenn du gleich am Anfang geschrieben hättest, dass es sich um ein teilweises Crossposting zu talk-de handelt 
Dort hat Roland Olbricht ziemlich gut und ausführlich beschrieben, an was es liegt/lag.
Ich gelobe Besserung. Ja, laut Roland routet OSRM nicht über construction=yes.
Laut wiki soll das übrigens nicht genutzt werden.
OSRM hätte weder über “construction=yes” noch über “under_construction=yes” stolpern dürfen
und noch weniger über construction=no.
Hallo,
Herzlichen Glückwunsch, das ist die Ursache.
OSRM verwirft Ways, die ein construction=*-Tag tragen, ausgenommen construction=no. Der Fehler ist bekannt.
construction=yes ist eine der ungeschicktesten Arten (aus der Perspektive eines Datenkonsumenten), wie man Tags verwenden kann. Ein untergeordnetes Tag (construction=) überschreibt die Bedeutung eines übergeordneten Tags (highway=). Wer nur das übergeordnete Tag auswertet (und dazu verleitet auch so sämtliche Doku zum Thema OSM), tappt in eine Falle, die glücklicherweise nicht allzu häufig mehr in OSM auftaucht. Zum Glück werten nur die wenigsten Dienste das aus, sodass Mapper nicht noch dabei unterstützt werden, es zu benutzen. OSRM wertet das Vorhandensein von construction=* zur sicheren Seite aus (darüber kann man sich streiten).
Die Layergruppe Hidden Non-Operational Tagging im OSM Inspector zeigt Fälle an, bei denen construction=* getaggt ist, aber nicht getaggt werden sollte. Meiner Meinung nach ist jeder Eintrag in diesem Layer ein Fehler und bedarf einer Korrektur. Vielleicht sollte man einen Patch für den JOSM-Validator schreiben?
Viele Grüße
Michael
danke für den Link 
Hab ich gleich mal bei mir geschaut… sind meist überbleibsel von ehemaligen Baustellen
Das construction-Tag ist aber nicht der (einzige) Grund, warum das Gambacher Kreuz nicht von der A5 zur A45 in OSRM benutzt wird. https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.46322%2C8.72108%3B50.46390%2C8.72158#map=19/50.46357/8.72126&layers=D
Alle beteiligten highway-Abschnitte der Route sind seit 2017 unangetastet.
Hier https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.4729%2C8.7350%3B50.4766%2C8.7202#map=13/50.4792/8.6882 habe ich noch nicht nachgeschaut, wie der Status ist.
Ich hatte heute morgen schon ein Ticket dazu aufgemacht: https://github.com/Project-OSRM/osrm-backend/issues/5568
Das ist unter Umständen nicht der richtige Ansprechpartner, wenn ich das richtig verstehe?
Edit: Mhh Ticket nicht genau genug gelesen, Du reproduzierst das auf einer lokalen Instanz. Bin gespannt wo der Fehler versteckt ist.