We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Thesis GraphHopper-Routing mit Maut-Erweiterung

00:00

Formale Metadaten

Titel
Thesis GraphHopper-Routing mit Maut-Erweiterung
Untertitel
Einen Versuch die OSM-LKW-Mautdaten in der GraphHopper-Direction-API zu integrieren
Serientitel
Anzahl der Teile
68
Autor
Lizenz
CC-Namensnennung 3.0 Deutschland:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Diese Arbeit beschäftigt sich mit der Routenberechnung unter Berücksichtigung von Straßenbenutzungsgebühren für LKWs (die sogenannte LKW-Maut) für Deutschland. Sie dokumentiert nicht nur den Entwurf und die Umsetzung einer Routenberechnung unter Berücksichtigung der LKW-Maut, sondern beschreibt auch eine kleine grafische Beispielanwendung (App) für mobile Android-Geräte. Diese App ruft exemplarisch nach Eingabe von Start und Ziel die eigene Berechnung auf und zeigt die gefundene Route grafisch an. Die Berechnung sucht nach einer Route, die aus den kostengünstigsten Mautsätze und der kürzesten Wegstrecke besteht. Dafür benötigt die Berechnung qualifizierte und problemspezifische Verkehrsdaten, die vorher aus frei verfügbare Datenquellen extrahiert und in einer, für diesen Zweck angepasste, Routing-Datenbank konsistent gespeichert werden. Als frei verfügbare Datenquellen dienen z.B. das freie Projekt OpenStreetMap (OSM) und deutsche Behörden. Implementiert werden die Funktionen, die in den einzelnen Prozess Schritten benötigt werden, auf Basis der quelloffenen Routingbibliothek der Firma GraphHopper. Eine wichtige Eigenschaft der App ist die Offline-Nutzbarkeit, wofür die benötigten Ausgangsdaten gezielt für eine Region lokal gespeichert und bei Bedarf jederzeit online aktualisiert werden können.
Schlagwörter
1
Vorschaubild
13:04
24
39
58
59
Vorschaubild
36:34
ErweiterungVisualisierungMessage sequence chartStatistische HypotheseBenutzeroberflächeErweiterungWeb logStatistische HypotheseInformationComputeranimationVorlesung/Konferenz
ErweiterungRoutingMessage sequence chartStatistische HypotheseUmsetzung <Informatik>BerechnungYES <Computer>APIRepository <Informatik>ClientHumanoider RoboterUpdateDateiZellulares neuronales NetzWEBAttributierte GrammatikGraphBerechnungMatrizenringDateiGruppoidStreckeKanteEckeParametersystemRoutingRouterRepository <Informatik>InternetTAXLaufzeitsystemGewichtungWeb-SeiteAustauschformatMeterBenutzerprofilMobiles EndgerätKoroutineProgrammiererVersion <Informatik>App <Programm>Computeranimation
Culling <Computergraphik>Umsetzung <Informatik>RouterClientOptimierungDateiErweiterungBerechnungRoutingVerzerrungServerLängeAnpassung <Mathematik>RoutingRouterInternetAchse <Mathematik>Web-SeiteClientViewerDrahtloses lokales NetzApp <Programm>GraphAggregatzustandBildschirmmaskeChipkarteSummeHöheComputeranimation
KanteRouterBerechnungKnotenpunktSchnittpunktVorlesung/Konferenz
Ableitung <Topologie>KnotenpunktStreckeKostenfunktionKnotenmengeComputeranimationDiagramm
FaktorisierungKostenfunktionStreckeHöheMessage Transfer AgentTOUR <Programm>QuellcodeVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
Willkommen zum zweiten Vortrag dieses Vormittagsblogs. Wir hören jetzt eine Erweiterung von Graf Hopper um Mautinformationen und Robert Klemm wird uns dazu seine Master Thesis präsentieren. Bitte, 20 Minuten.
Vielen Dank. Guten Morgen. Ja, ich möchte gerne über meine Master Thesis, ich möchte sie vorstellen. Es geht eigentlich mehr darum, um einen Versuch, die USM-Eckarm-Mautdaten in Graf Hopper zu implementieren, in der Direction API und habe eben versucht, daraus eine App zu generieren und will
das natürlich gerne mal vorstellen. Ganz kurz eine kleine Einleitung, eine Problemstellung, warum ich das überhaupt gemacht habe, was mich bewegt hat, das zu machen, wie ich das umgesetzt habe. Zum Schluss ein paar Screenshots von dieser wunderschönen App und zum Schluss eine kleine
Zusammenfassung. Ja, warum habe ich dieses Thema überhaupt gewählt? Ich hatte im Jahr 2015 in Münster auf der Forstgis hatte ich damals meine Bachelorarbeit präsentiert. Damals ging es um die Auswertung von USM-Daten und der Mautattribute für LKWs und wollte das natürlich weiter
fortführen. Natürlich gab es in den letzten Jahren in den Medien immer neue Schlagzeilen, sage ich jetzt mal, also natürlich, dass die LKW-Maut erweitert wird. Natürlich auch das Thema PKW-Maut, was natürlich viele sehr interessiert. Andererseits wollte ich
auch eigentlich mal eine App programmieren. Das habe ich mir immer mal auf die Agenda geschrieben und jetzt hat es eigentlich mal geschafft. Und genau, noch mal ein kurzer Rückblick. Ja, Toll Collect sagt jedem, glaube ich, etwas. Toll Collect hat es im Jahr 2005 geschafft, eine Mauterfassung durchzuführen, also ein System aufzusetzen, dass die Autobahn
ab zwölf Tonnen der LKW bemautet. 2012 wurden dann die Bundesstraßen, ausgewählte Bundesstraßen, hinzugekommen. Und im Jahr 2015 wurde dann die Tonnage gesenkt von zwölf Tonnen auf 7,5. Und aktuell ist geplant im Juli 2018, dass alle Bundesstraßen bemautet werden ab
7,5 Tonnen, wo bisher die Busse, also Fernbusse, ausgenommen sind. Zukunftsidee kann natürlich dann sein, dass die Tonnage weiter gesenkt wird auf 3,5 Tonnen. Vielleicht dann noch weiter, dass wir dann alle zahlen müssen, auch dann Radfahrer, wer weiß. Vielleicht dann auch die
Fernbusse. Mal gucken, was die Zukunft bringt. Noch mal ein Rückblick. Das ist das Bau-Tacking-Schema, was ich benutzt habe aus dem USM-Wigi. Das ist ja seit Jahren schon drin und hab das eigentlich nur genommen und fortgeführt. Und das ist eben doch wichtig in Graf Hopper, dass
man in dem Routing-Profil die USM-Texts hinterlegt, die dann für die Kostengewichtung und Analyse wichtig sind. Warum habe ich das eigentlich gemacht? Ich hatte damals, letztes Jahr, wo ich die Masterarbeit geschrieben habe, festgestellt, na ja, so eine
richtige Routing-API, also die freie Routing-API gibt es nicht so. Graf Hopper ja, aber Thema spezifisch auf LKW-Profilen, das ist eher noch so eine Grauzone. Und das war mir wichtig, ja, ich versuch's mal. Wichtig war auch, dass die USM-Daten eben auf Konsistenz überprüft werden in meinem
Workflow. Und natürlich war es auch sehr wichtig, dass man eben nicht die kürzeste Strecke routet, sondern auch die mautkosten-günstigste Strecke, was natürlich den Logistikfirmen wahrscheinlich sehr nahe liegt, weil die das haben möchten. War ja Zeit ist Geld. Und für mich war wichtig, dass das auf mobilen Endgeräten auch funktioniert und dass es auch offline
geht. Somit haben sich da meine Ziele ein bisschen kristallisiert. Mir war wichtig, eine kostengünstigste, schnellste Route zu generieren, dass man über die App eben auch USM-Daten runterladen kann und auch die Mauttarife. Und dass man eben die Mautparameter eintippen kann und
die Routing-Profile auswählen kann. Was habe ich genommen? Ich habe eben versucht, so weit wie möglich Open-Source-Technologie zu benutzen. Ich habe mich also ganz auf dieses GrafHopper-Framework gestürzt. Einmal das Repository. In dem Repository ist dieses GrafHopper-SDK drin,
also das heißt diese Demo-App. Die dient komplett als Grundlage für meine Masterarbeit und habe natürlich dann die Mautdaten aus USM extrahiert und aufbereitet und die Mauttarife von der Webseite genommen, weil die momentan noch nicht als Austauschformat vorrätig sind.
Ja, da mein Workflow war, es sind vier große Grundsäulen. Als erstes habe ich die Mauttarife, wie ich schon meinte, von der Webseite eben genommen und habe die in ein Skript, in einer Datei umgeschrieben und dass man die automatisiert auslesen kann.
Zum Schluss habe ich dann das GrafHopper-Repository erweitert und angepasst, wo verschiedene Sachen eben notwendig waren. Und zum Schluss natürlich ein Android-Projekt. Das von GrafHopper habe ich weiter genommen und natürlich auch angepasst. Nach den bestimmten Richtlinien, die ich haben wollte, Offline-Rooting,
dass die LKW-Mautberechnung stattfindet und das Mautdaten-Update. Natürlich zum Schluss soll das ja auch alles getestet werden. Deswegen die vierte Grundsäule. Man sollte ja auch ein bisschen gucken, ob es funktioniert. Was habe ich als erstes gemacht? Man sieht jetzt recht, das ist jetzt abstrakt, es ist jetzt einfach mal die Webseite von Tollcollector, da sind die Mauttarife eben aufgelistet.
Die habe ich umgeschrieben hier unten im Bild als in einer CSV-Datei und habe dazu einen PASA geschrieben in Java und der das dann umwandelt, die CSV-Datei in ein JSON-Format, was ich dann später in Android,
in der Android-Umgebung benutze zur Aktualisierung. Ja, dann in GrafHopper direkt habe ich so verschiedene Workflows. Also ich habe das jetzt mal links im Bild sieht. Man versucht aufzuschlüsseln, abstrakt. Ich habe als erstes ein Rooting-Profi erstellt.
Wichtig war natürlich, dass die USM-Maut-Tacking, also das Schematar hinterlegt sind, dass es ausgelesen werden kann. Habe versucht, die LKW-spezifischen Parameter mit einfließen zu lassen, also die Höhe, die Breite, das Gewicht natürlich,
das dann später in der Kostenmatrix berücksichtigt wird und danach gebootet wird. Genau, dann habe ich das in Java eingestellt, habe dann in GrafHopper tief in GrafHopper eine eigene Java-Methode geschrieben. Zum Schluss dann ein paar Skripte angepasst. Und ja, was dann natürlich rauskommt, ist dann ein Konstrax,
eine Hierarchie, das ist quasi das Endprodukt, was ich dann später in der mobilen Version dann brauche. In der Mitte des Bildes mal abstrakt dargestellt. In meinem Workflow, der Entwickler quasi importiert die USM-Daten als binäres File, das WWF-Format, mit den GrafHopper Core.
In den GrafHopper Core führt das aus. Und das ist jetzt ganz abstrakt. GrafHopper geht dann jede Kante durch, ob das Tagging-Schema vorhanden ist, also die Kriterien und Regeln, wertet die aus in Kostenpunkte und die in den Truck-Flag-Encoder hinterlegt sind
und setzt dann auf die Kante gewisse Kostenmatrizen. Und die berechnete Werte werden dann vorgehalten in den Core und später werden die dann auf den Kanten gespeichert. Genau, das ist jetzt mal ganz grob. Zum Schluss habe ich dann das Android-Projekt natürlich dann mir angenommen
und habe es mal erweitert und angepasst. Wichtig war hier, dass ich die verschiedenen Java-Biliotheken von GrafHopper und meine natürlich mit implementiere. Wichtig dabei ist dieses Maut-Jasen-File, was Sie hier rechts im Bild sehen, die Struktur, dass es eben ausgewertet wird. Und jedes Mal, wenn man jetzt die App eben ausführt,
wird dieses Jasen-File eben genutzt und daraus die Maut berechnet. Wichtig waren natürlich die Anwendungsfälle, die ich ja vorher schon erwähnt hatte. Hier habe ich sie noch mal klar hingeschrieben, Verkehrsdaten auswählen. Die Maut-Datentarife aktualisieren. Die Mautparameter natürlich eingeben für den LKW-Fahrer
und zum Schluss natürlich die Routenberechnung. Wie sieht das ungefähr aus? Ich habe jetzt hier nun einen ganz kleinen Ausschnitt genommen, weil das ist ein riesen Projekt und ich wollte natürlich nicht alles zeigen, weil das würde den Rahmen sprengen. Ich habe mich jetzt spezifisch mal auf die abstrakte Darstellung von GrafHopper mal gestützt. Das ist jetzt hier sehr abstrakt.
GrafHopper in dem Fall ganz grob erklärt. Der User tippt dann Start-Ziel ein. Diese Start-Ziel-Koordinaten werden in den GrafHopper übergeben, in der API, die dann quasi auf dem lokalen mobilen Gerät läuft. Die werden dann ausgewertet und dann weiter übergeben.
Und später wird die Route genau geguckt, welche ist nun mal die optimierte und schnellste Route. Und auf den Grundlagen wird dann die Maut berechnet. Zum Schluss werden dann die Ergebnisse dann mobile gerendert. Wie sieht das ungefähr aus? Ja, ich habe jetzt hier mal ein paar Screenshots gezeigt,
weil das geht ein bisschen schneller, als das über dem Handy zu zeigen. Im Vorfeld musste ich natürlich meine Grafen generieren. Das sind jetzt alle mal verpackt unter den drei Bundesländern, Brandenburg, MacPom und Berlin. Und wichtig natürlich, dass man ein Map-File,
das ist typisch für MapForge, dass man das auch hinterlegt. Das habe ich natürlich im GrafHopper-Script mit eingearbeitet, im Vorfeld, dass es automatisch runtergeladen wird und in den Ordner gespeichert werden. In diesem Fall ist es so, dass dieses Handy jetzt offline ist. Das sieht man daran, dass oben bei Server das Feld ausgegraut ist.
Das heißt, das Handy hat keine Internetverbindung. Somit kann man nur die lokalen hinterlegten Grafen auswählen, was man hier auch rechts im Bild sieht. Und der Graf wird dann ausgewählt und in der Mitte sieht man dann, dass man die Mautkategorie und die Achtszahl auswählen kann.
Das sieht man jetzt beispielhaft dann in der nächsten Folie. In dieser Folie ist jetzt beispielhaft bei erklärt, wenn das Handy doch Internet hat, vorzugsweise natürlich WLAN. Dann kann man auf den FDP-Server, den ich da eigens angelegt habe, dann dieses Grafen-File runterladen.
In diesem Fall ist das gezippt, um die Bandbreite ein bisschen zu reduzieren. Das wird automatisch runtergeladen, entzippt und in diesem Fall in den Download-Ordner lokal auf der SD-Karte im mobilen Client gespeichert. Noch mal zurück zu dieser Mautkategorie.
Der User kann dann reinklicken und dann werden die verschiedenen Mautkategorien angezeigt. In diesem Fall A bis F. Ich habe mich da orientiert an Tollcollect auf diese Webseite. Und Achtszahl von zwei bis fünf Achsen. Wenn der User das alles ausgewählt hat,
dann kann er rechts, was man im Bild auch sieht, das ist markiert, auf Start klicken. Und dann wird eine neue View gerendert. In diesem Fall ist das jetzt Brandenburg. Der User kann dann die Start- und Zielpunkte eingeben. Und der Client fängt dann automatisch an zu rechnen
und sucht natürlich im Hintergrund auch, ob da die Punkte auch gemapped werden können. Genau, wenn die Route gefunden wurde, wird dann die View in zwei verschiedene Farben angezeigt. In diesem Fall Rot und Grün. Rot heißt Maut, Grün ist keine Maut. Genau, und zum Schluss natürlich wie überall wird dann die Gesamtroute angezeigt und dazu die Maut.
Ja, dann dachte ich, wow, das klappt. Ich habe etwas geschafft und dann dachte ich mir, naja, ich sollte mal das Ergebnis weiter betrachten. Habe drei verschiedene Beispielrouten mal generiert im Fall von Brandenburg
und habe die mal verglichen miteinander und habe natürlich mal durchgerechnet, was sagt Tollcollect oder die Behörde. Weil die Abschnitte, die Mautabschnitte sind ja fest verankert und die sind fest definiert und habe die Routen mal verglichen bzw. die Tariflängen und habe festgestellt,
oh, ich habe einen entscheidenden Punkt, da habe ich ein bisschen was vergessen, und zwar an die Projektion. Grafhopper benutzt in diesem Fall WGS 84 und die Bass in diesem Fall, die quasi die Tariflängen vorbestimmt, rechnet aber in UTM und habe festgestellt, es gibt gewisse Abweichungen. In diesem Fall sieht man das unten links im Bild.
Grün ist die Bast, das ist quasi mein Ausgangswert. Rot ist in diesem Fall WGS 84 und blau ist quasi die UTM Koordinatensystem. Und habe festgestellt, oh, da gibt es doch gewisse Abweichungen. Klar, die Verzerrung spielt eine große Rolle. Andererseits ist mir dann aufgefallen, klar, ich habe dann in UTM das umgeprojektiert
und habe festgestellt, oh, in diesen drei Beispielrouten sind die Routen sogar kürzer als angegeben und das hat natürlich zur Folge, es hat viele Ursachen. Erstens ist die Mautdetektion in USM noch nicht so ganz klar definiert.
Andererseits ist das auch ein bisschen schwierig, genau abzubilden, was ich natürlich damals in 2015 in Münster auf der Forstgist ja auch schon erzählt habe. Deswegen hatte ich ja dieses Qualitätsmanagement-Tool versucht zu generieren. Ja, was heißt das?
Oh, ich bin ja schnell. Okay, das heißt, ich habe eine App entwickelt, die versucht auf Grundlage von Graf Hopper ein mautspezifisches Routing zu routen.
Es ist kostenfrei. Man kann verschiedene Profile hinterlegen. Also das heißt, jeder LKW kann seine eigenen Merkmale hinterlegen, wie Höhe, Breite oder Länge. Und was natürlich auch interessant ist, man könnte dieses System, was ich da entwickelt habe, auch auf andere Mautsystem übertragen. Also jetzt zum Beispiel in Tschechien, hier in Österreich oder in anderen EU-Ländern.
Und natürlich habe ich mir dann als Änderungsvorschlag auch mal auf die Fahne geschrieben, die Routing-Profile weiter anzupassen, mehr Routing-Profile zu erzeugen und die kostengünstigste Mautroute zu berechnen. In diesem Fall hat die Zeit leider in meiner Masterarbeit nicht gereicht,
um quasi dieses Thema weiter voranzutreiben. Deswegen wurde bisher nur die schnellste Route berechnet, weil die kostengünstigste Route hätte noch mehr Anpassungen im Graf Hopper-Core zur Folge gehabt. Und zum Schluss natürlich, dass man die App weiterentwickelt.
Das war jetzt nur eine Demo-App und ja, das sind so meine Änderungsvorschläge. Und ja, bin ja mal schnell durchgeritten. Vielen Dank für Ihre Aufmerksamkeit. Vielen Dank, Robert. Gibt es Fragen zu dem Vortrag?
Wenn du bei der Distanzberechnung eine Abwechslung von 20, 30 Prozent hast, dann rechnest du nicht in geografischen Koordinaten, sondern wahrscheinlich in Mercato?
Ja, danke. Erstmal, ich finde das eine super Arbeit. Mich würde interessieren, du hast jetzt sehr oft die User angesprochen und auch mal in so einem Nebensatz, die Logistikfirmen würden dann wahrscheinlich die kostengünstigste Route bevorzugen. Also mich würde interessieren, ob du einen nutzerorientierten Ansatz gewählt hast oder die potenziellen Nutzer komplett rausgelassen hast bei deiner Entwicklung.
Und ob das dann nicht der nächste Schritt wäre, weil du sagst, dass so eine kostengünstigste Route vielleicht interessant wäre, an dem Punkt die potenziellen Nutzer mit einzubeziehen. Ja, das stimmt. In diesem Fall habe ich einfach nur getestet, ob überhaupt machbar ist. Natürlich im nächsten Ansatz, wie Sie schon meinten,
würde ich dann die kostengünstigste Variante wählen und mal gucken, ob man dann für die Logistikfirmen auch bestimmte Profile anlegen kann. Das habe ich jetzt nicht gemacht. Ich wollte einfach nur wissen, funktioniert überhaupt das, was ich jetzt überlegt habe? Es ist machbar, mit viel Aufwand. Aber ja, ich bin doch ganz angetan von der Sache, dass es doch funktioniert hat.
Ja, auch danke. Sehr interessant. Wie einfach oder schwierig ist das denn, auf die mautgünstigste Route zu optimieren?
Das ist ja ein unterschiedlichen Mautsystem, unterschiedlich einfach. Ist das denn leicht auf Kanten umlegbar, das Tollcollect-Mautsystem? Ich kenne das überhaupt nicht. Oder ist das so was wildes zonenorientiertes, wo man globale Dinge angucken muss? In diesem Fall ist es ein bisschen schwierig, weil jedes EU-Land ihre eigene Mautsysteme hat.
Jeder kocht sein eigenes Süppchen. Und in diesem Fall hier in Deutschland ist es so, dass wir hier eine sattlikengestützte Maut haben und da werden die die Tariflenk vorbestimmt. Und dann auch auf die Kanten auf? Genau, auf die Kanten. Und das Problem ist aber, dass man jetzt nicht einfach sagen kann, man nimmt jetzt einfach die nächste Auf- und Abfahrtkante.
Das geht nicht. Tollcollect, also in diesem Fall die BAST, das Bundesamt für Straßenwesen, hat das generalisiert. Die haben ihre Schnittpunkte, also ihre Auf- und Abfahrtsknotenpunkte, haben die auf Brückenbauwerke gelegt. Und somit ist es schwierig, das eben abzubilden. Weil wenn man jetzt die Auf- und Abfahrtskanten nimmt,
nur und sagt einfach, wenn man rauf fährt, ab da fängt die Maut. Und dann die nächste, das kann ich Ihnen mal kurz zeigen. Die habe ich nämlich ausgeblendet, die Folie. Oh, zeigt er jetzt die an?
In diesem Fall ist es so, also hier im Bild, weil ich dachte, ich schaffe das mit der Zeit nicht, dass Sie mich einfach voll weggelassen. In diesem Fall sehen Sie hier, das ist der Mautknotenpunkt von Havaz.
Und OSM sagt eben, ab diesem Kreuzungspunkt ist Maut wichtig. So, und da kann es zu Generationensproblemen kommen. Und das ist jetzt hier, in jedem Fall ist das jetzt B96 bei Schönefeld. Und ein anderes Beispiel, was ich eben meinte mit den Auf- und Abfahrten,
ist dieser Punkt. Da sieht man das eben sehr gut. Hier oben rechts, das ist jetzt in Groß Bern, die Auffahrt. Und das Booting-System hat eben gesagt, okay, ab der Strecke, wo Maut ist, ich fahre quasi rauf und fahre wieder ab.
Aber treu kollekt zahlt, also in diesem Fall fast, die Maut wird berechnet von dieser Brücke bis zur linken Brücke oben rechts. Und deswegen habe ich auch in Hubis das nachgemessen, weil ich das nicht einsehen konnte, so richtig, äh, warum gibt es da diese Differenz von 0,3, sagt Carfhopper und was sagt ein Kilometer? Und habe dann nachgemessen, oh, das stimmt wirklich,
wenn man wirklich von Knot zu Knotenpunkt rechnet und deswegen ist es schwierig, das abzubilden. Ich hatte auch überlegt, man könnte ja eine Relation einführen in den USM, aber das will keiner so richtig. Deswegen habe ich das gleich wieder verworfen, weil Relation, das ist immer so ein Thema für sich. Und deswegen ist es schwierig und deswegen will ich diese Mauterfassung,
was ich in Münster erklärt habe, noch weiter fortführen und damit genau diese Strecken erfasst werden. Deswegen ist es generell ein bisschen schwierig in anderen EU-Ländern, aber es ist machbar. Also meine Frage ist, ich glaube, ich habe dich so verstanden,
du hast Mautvermeidung jetzt noch nicht direkt implementiert, aber siehst das als sinnvolles Feature. Meine Frage ist, kann das überhaupt funktionieren? Also besonders dann, wenn man als Kostenfunktion nicht nur die Mautkosten nimmt, sondern die Gesamtkosten aus Fahrzeugkosten, Treibstoff, Zeit, Unfallgefahr. Also eine realistische Kostenfunktion aus Sicht des Nutzers.
Und dann ist es ja so, dass sobald Mautvermeidung funktioniert, weil es plötzlich irgendwo eine lukrative Bypass-Strecke gibt, dann wird die ja dicht gemacht mit dem Durchfahrtsverbot. Das heißt, ich glaube, das System ist ja selbst regulierend. So, dass Mautvermeidung eigentlich nicht funktionieren kann. Oder was meinst du dazu? Ja, in diesem Fall dieses Tour. Ich sehe das eher mehr, dass es nicht aktiv,
also wirklich so Live-Navigation technisch funktioniert, sondern eher mehr als Planungsgrundlage. Und da könnte man natürlich so eine, ich sage jetzt mal, Mautvermeidung vielleicht mit implementieren. Aber es ist schwierig, wenn man das im Live-System routet, dass dann in verschiedenen Faktoren irgendwie auch Staus und so, und diese schon meinten Spritkosten und dann die Höhen und so,
das kann man natürlich machen. Aber ich denke mal, ich bin optimistisch, das könnte man mit implementieren, so eine Mautvermeidung. Wäre natürlich dann auch ein schönes Future, natürlich. Ging mal von anderen, Routing-System. Eine kurze Frage meinerseits. Wie geht es jetzt mit dem Projekt weiter?
Hast du vor, das in Doct-Arbeit weiterzuführen? Hast du vor, das als Open Source zu veröffentlichen? Ja, also momentan ist das so. Ich hatte überlegt, mich selbstständig zu machen. Also mit diesem Thema habe dann festgestellt, in der Marktanalyse ist das ein bisschen schwierig. Es gibt viele große Firmen hier, besonders in Deutschland, die sich darauf spezialisieren,
eben verschiedene Portfolios anzubieten. Und momentan ist es dann eher mehr so ein Abseits jetzt gelandet und macht das jetzt hobbymäßig weiter. Vielleicht hat jemand Interesse, mit einzusteigen. Ja, Docto-Arbeit weiß ich noch nicht. Aktuell bin ich auf Job-Suche und vielleicht ergibt sich ja was.
Gibt es noch weitere Fragen? Wenn nicht, dann noch einen Applaus für Robert.