Routing- und Optimierungs-API: was Sie wirklich brauchen.

Zwei Dienste, ein Begriff

Wer eine Routenoptimierungs-API sucht, sucht in Wahrheit meist zwei Komponenten, die unterschiedliche Aufgaben lösen und sich unabhängig voneinander austauschen lassen:

• Die Routing-Engine. Sie kennt das Straßennetz und beantwortet zwei Fragen: Wie komme ich von A nach B (Geometrie, Dauer, Distanz), und wie lang ist jede Verbindung zwischen einer Menge von Punkten (Distanzmatrix). Sie optimiert nichts – sie misst.
• Der Solver. Er bekommt die Matrix, die Aufträge, die Fahrzeuge und die Restriktionen und entscheidet, welcher Auftrag auf welches Fahrzeug kommt und in welcher Reihenfolge. Er kennt keine Straßen, nur Zahlen.

Diese Trennung ist der wichtigste Punkt der ganzen Architektur. Sie erlaubt es, die Engine zu wechseln, ohne die Optimierung anzufassen – und umgekehrt. Und sie erklärt, warum ein Dienst, der nur Wege berechnet, Ihr Planungsproblem nicht löst, auch wenn er „Route“ im Namen trägt.

Die Distanzmatrix bestimmt den Preis

Der Solver braucht die Fahrzeit zwischen allen Punktpaaren, nicht nur entlang einer geplanten Route. Bei n Stopps sind das n² Werte. Hundert Stopps ergeben zehntausend Paare, fünfhundert Stopps eine Viertelmillion – und das für jeden Planungslauf, oft mehrmals täglich.

Genau hier entscheidet sich die Wirtschaftlichkeit. Gehostete Kartendienste rechnen typischerweise nach Matrixelementen oder Anfragen ab; die quadratische Zunahme trifft die Rechnung deshalb härter als das lineare Wachstum der Stoppzahl vermuten lässt. Wer regelmäßig große Matrizen braucht, kommt schnell an den Punkt, an dem ein eigener Server günstiger ist als die Abrechnung – zumal Matrizen für dieselben Adressen oft wiederverwendbar sind.

Der offene Stack

Der Grund, warum sich Eigenbetrieb überhaupt lohnt: Die tragenden Bausteine sind quelloffen und ausgereift. Dieselben Komponenten stecken – teils unverändert – in kommerziellen Planungsprodukten.1

• OSRM – sehr schnelle Routing-Engine mit exzellenter Matrixleistung. Vorberechnet stark, dadurch zügig im Betrieb und weniger flexibel bei Profiländerungen.
• Valhalla – flexibler, mit dynamischen Kosten je Anfrage, Zeitabhängigkeit und brauchbarem Lkw-Profil. Etwas langsamer als OSRM, dafür anpassbar ohne Neuberechnung.
• OR-Tools – der Solver von Google für Vehicle-Routing-Probleme mit Zeitfenstern, Kapazitäten, mehreren Depots und Ressourcenbeschränkungen. Sehr mächtig, entsprechend viel Modellierungsarbeit.
• VROOM – schlanke Solver-Schicht mit klarer JSON-Schnittstelle, die Routing-Engine und Optimierung zusammenführt. Guter Startpunkt, wenn das Modell nicht exotisch ist.

Alle vier arbeiten auf OpenStreetMap-Daten. Das ist Stärke und Grenze zugleich: Die Abdeckung ist in Deutschland ausgezeichnet, Lkw-relevante Attribute wie Durchfahrtshöhen, Tonnagebeschränkungen und Brückenlasten sind aber lückenhaft erfasst. Für Pkw-Routing ist das unerheblich, für Schwerverkehr nicht.

Wann eine gehostete API die richtige Wahl ist

Der Eigenbetrieb ist kein Selbstzweck. Ein gehosteter Dienst ist die vernünftigere Wahl, wenn Ihre Anforderungen im Standard liegen: Pkw- oder leichtes Nutzfahrzeugrouting, moderate Matrixgrößen, Bedarf an aktueller Verkehrslage, kein Team, das einen Kartendienst betreiben möchte. Verkehrsdaten in Echtzeit sind ein Argument, das der offene Stack nicht ohne Weiteres liefert.

Der Eigenbetrieb wird interessant bei großen oder häufigen Matrizen, bei Datenschutzanforderungen, die gegen die Übermittlung von Kundenadressen sprechen, bei benötigter Reproduzierbarkeit – ein gehosteter Dienst kann seine Ergebnisse jederzeit ändern – und immer dann, wenn das Fahrzeugprofil vom Standard abweicht.

Integrationsmuster, die sich bewährt haben

Optimierungsläufe sind keine Web-Requests. Ein Lauf über einige hundert Stopps dauert Sekunden bis Minuten – das passt in kein Anfrage-Antwort-Zeitfenster, das ein Browser oder ein vorgelagerter Proxy toleriert.

• Auftragsbasiert statt synchron: Ein POST legt den Lauf an und liefert eine ID, der Status wird abgefragt oder per Webhook gemeldet. Das erspart Timeouts und macht Wiederholungen unkritisch.
• Idempotenzschlüssel je Lauf: Planungsläufe werden bei Netzwerkfehlern wiederholt. Ohne Schlüssel entstehen doppelte Pläne, und die Disposition sieht zwei Wahrheiten.
• Rechenzeit als Parameter, nicht als Zufall: Solver liefern nach jeder Sekunde eine bessere Lösung. Ein festes Zeitbudget macht Läufe planbar und Ergebnisse vergleichbar.
• Die Baseline mitliefern: Jede Antwort sollte enthalten, was der Plan gegenüber dem Ist-Zustand ändert. Ohne diese Differenz kann niemand im Betrieb beurteilen, ob der Vorschlag angenommen werden soll.

Der letzte Punkt ist der, der über die Akzeptanz entscheidet. Eine API, die einen Plan ausgibt, wird in der Disposition misstrauisch beäugt. Eine API, die sagt „diese Zuordnung spart 62 Kilometer und verletzt kein Zeitfenster“, wird benutzt.

Wenn Ihr Wegenetz nicht in der Karte steht

Es gibt eine Klasse von Anwendungen, für die keine gehostete API und kein Standardprofil funktioniert: wenn das Wegenetz gar nicht öffentlich kartiert ist. Werksgelände, Hafenanlagen, Forst- und Feldwege, Bergbau, militärisches Gelände – dort endet OpenStreetMap, und dort beginnt die eigentliche Modellierungsarbeit.

In diesen Fällen ist die Frage nicht, welche API man einkauft, sondern wie das eigene Netz zu einem routingfähigen Graphen wird: Wege mit Tragfähigkeit, Breite, Steigung und Untergrund, fahrzeugspezifische Befahrbarkeit, saisonale Sperrungen. Genau das ist die Aufgabe, für die eviit Custom Routing baut – und die Grundlage unseres eigenen Produkts X-PLORE für Offroad-Navigation.

Die Reihenfolge, die Geld spart

Für Entwicklerteams, die vor dieser Aufgabe stehen, hat sich diese Reihenfolge bewährt – sie beantwortet die teuren Fragen zuerst:

• Matrixgröße und Laufhäufigkeit abschätzen. Diese beiden Zahlen entscheiden zwischen gehostet und Eigenbetrieb, und zwar bevor irgendein Anbieter verglichen wird.
• Das Fahrzeugprofil prüfen. Passt Ihr Fahrzeug in ein Standardprofil? Wenn nicht, welche Attribute fehlen – und stehen sie überhaupt in irgendeiner Karte?
• Restriktionsliste schreiben, bevor ein Solver ausgewählt wird. Sie bestimmt, ob VROOM genügt oder ob es OR-Tools mit eigenem Modell sein muss.
• Mit einem Prototyp auf echten Daten anfangen, nicht mit einem Anbietervergleich. Ein Wochenende OSRM plus VROOM auf einem Export sagt mehr als drei Angebote.

Wenn Sie an dieser Stelle nicht anfangen wollen, sondern eine Zahl brauchen: Der Tourenoptimierungs-Check beantwortet genau die Frage, die vor jeder Architekturentscheidung steht – wie groß das Potenzial in Ihren Daten überhaupt ist. Die begriffliche Einordnung dazu steht in Tourenoptimierung.