Da bin ich ja mal gespannt: https://www.bmvi.de/SharedDocs/DE/Artikel/DG/mfund-projekte/tardur.html?nn=326002. Zu schade, dass das wohl mit OSRM nicht möglich ist 
„Bis dato wird eine wichtige Eigenschaft infrastruktureller Straßennetzdaten in noch keiner frei verfügbaren Routing Anwendung voll ausgenutzt: zeitliche Restriktionen auf Straßen und Wegen, wie etwa tageszeit- oder saisonale Fahrbahnbeschränkungen.“
weiß mans? Die proprietären Anbieter sagen einem ja nicht wie sie zu ihren Ergebnissen kommen, aber bei den Großen, die auch Zugriff auf Massen von realtime Daten ihrer Nutzer haben, ist das sicherlich auf die ein oder andere Weise eingepreist. Für OSM Mapper ist das ein alter Hut, wir machen das schon längst, da haben sie extra „voll“ ausgenutzt schreiben müssen, damit es stimmt. Weil „voll“ wird es niemand je erreichen 
Die Beschreibung erwähnt keine Echtzeitdaten, sondern nur das, was wir bei OSM unter “Conditional restrictions” (access:conditional=* usw.) verstehen. Wenn ich mich recht erinnere, gibt es im Navstreets-Datensatz Informationen über solche Beschränkungen.
Kann es sein, dass „frei“ hier wie Freiheit zu verstehen ist, nicht frei wie Freibier? Wenn man sich nämlich wirklich auf freie Software (frei wie Freiheit) beschränkt, könnte die Aussage tatsächlich wahr sein.
Da die GraphHopper GmbH einen Fork einer älteren [1] Version des Mapbox Navigation SDK für Android als eigene Android-Beispiel-App, gibt es einen rudimentären Mapbox-API-Endpoint auf Basis der GraphHopper-Routing-Engine. Das war ursprünglich dieser Pull-Request, ist dann aber – vermutlich aus IMHO nachvollziehbaren architektonischen Gründen – in ein separates Projekt ausgegliedert worden.
Die Schnittstellen der Mapbox-Routing-API und der OSRM-Routing-API scheinen nicht kompatibel zu sein. Der eingeschlagene Weg zeigt aber auf, dass es möglich sein dürfte, eine zumindest rudimentäre OSRM-API auf GraphHopper-Basis zu betreiben. So vom Gefühl her dürfte das einfacher als mein Eisenbahnrouter auf GraphHopper-Basis sein, für den ich meinen eigenen GraphHopper-Fork pflege.
[1] damals noch 100% freie Software, später hat Mapbox dann dem Projekt eine unfreie Bibliothek untergejubelt.
Also in BRouter baue ich das auch für weniger als 134.000 Euro ein…
Und verstehe auch nicht so richtig, wieso das technologische Problem so gewaltig sein soll.
Bei OSRM meinst Du wohl den CH-Algorithmus (Contraction Hirarchies)? Das man damit jegliche Flexibiliät verliert hat sich wohl mittlerweile rumgesprochen. Aber bei GraphHopper (um den es hier geht) reden die ja seit einiger Zeit von “Landmarks” als Speed-Up Technik:
https://www.graphhopper.com/blog/2017/08/14/flexible-routing-15-times-faster/
und das steht da ja in den Projektzielen, dass es dafür funktioniert.
Trotzdem schade, dass solche Fördergelder wieder mal nur für algorithmische Spielereien locker gemacht werden und nicht für das eigentliche Problem, nämlich die Modellierung solcher Restriktionen voranzutreiben und die Datenqualität zu verbessern.
Jedenfalls hab ich ja schon einen Testfall an dem sie sich messen lassen müssen:
https://forum.openstreetmap.org/viewtopic.php?pid=670861#p670861
Die mFund Anträge bewertet der TÜV Rheinland im Auftrag des Bundesverkehrsministeriums in Berlin.
So ein Antrag im Verbund mit einer Hochschule ist da wohl ganz gerne gesehen. Also alles richtig gemacht und ist ja eine gute Nachricht, dass sie Projekte mit OSM Bezug fördern.