OpenRouteService

Kurzfazit

OpenRouteService ist die ernsthafteste DSGVO-konforme Alternative zu Google Maps Directions und Mapbox, kostenlos für überschaubare Volumina, vollständig Open Source und betrieben von einem gemeinnützigen Forschungsinstitut der Universität Heidelberg. Die gehostete API liefert ohne Kreditkarte zwei- bis dreitausend Routen pro Tag, mit EU-Servern und ohne langwierige AVV-Verhandlung. Für KI-gestützte Tourenplanung, Außendienst-Routing und Standortanalysen ist das einer der wenigen Routing-Backends, den auch deutsche Behörden, Krankenhäuser und Logistiker bedenkenlos einsetzen können. Es ist keine KI-Anwendung im engen Sinne, sondern ein algorithmisches Routing-Backend, das in Kombination mit Optimierungs- und ML-Komponenten zum Rückgrat moderner KI-Logistik wird. Schwächen: OSM-Datenqualität variiert regional, kein Echtzeit-Verkehr, und die Optimization-API ist im Free-Tier eng begrenzt.

Für wen ist OpenRouteService?

Logistiker und Disponenten: Wer Touren für Lieferfahrzeuge, Außendienstler oder Servicetechniker plant, bekommt mit dem Directions- und Matrix-Endpoint eine solide Grundlage. Der Optimization-Endpoint löst klassische Vehicle-Routing-Probleme mit Zeitfenstern und Fahrzeugkapazitäten, für kleinere Flotten bis ca. 50 Stopps pro Tour direkt nutzbar, für größere Probleme als Baustein in eigenen Solvern.

Reinigungs-, Pflege- und Servicedienste: Branchen mit täglich neuen Tourenplänen über 20–80 Objekten profitieren erheblich. OpenRouteService liefert die Distanzmatrix und Routen, die eigene Optimierungsschicht (oder ein KI-Modul) trifft die Reihenfolge-Entscheidung. So wird aus einer 90-minütigen Excel-Planung ein 5-Minuten-Job.

Öffentlicher Sektor und Gesundheit: Verwaltungen, Behörden, Krankenhäuser und ÖPNV-Planer können OpenRouteService einsetzen, ohne sich durch Datenschutzgremien quälen zu müssen. Das EU-Hosting in Heidelberg, die akademische Trägerschaft und die offene Quelle senken die Compliance-Hürde drastisch.

Standort- und Marketing-Analysten: Isochronen (“Welche Gebiete erreiche ich in 15 Minuten per PKW?”) sind das Mittel der Wahl für Einzugsgebiet-Analysen, Filialstandort-Bewertung und Außendienst-Gebietszuschnitt. OpenRouteService liefert diese Berechnungen kostenlos in einer Qualität, die kommerziellen Anbietern in nichts nachsteht.

Entwickler und Open-Source-Anwender: Wer die Kontrolle über die gesamte Routing-Pipeline behalten will, kann den Backend-Stack selbst hosten, komplett ohne Vendor-Lock-in. Das ist mit Know-how und Hardware-Budget machbar, aber kein Wochenend-Projekt.

Weniger geeignet für: Anwender ohne Entwickler-Ressourcen (die API ist kein No-Code-Produkt), Unternehmen, die Echtzeit-Verkehrsdaten brauchen (Google Maps Platform oder TomTom bleiben überlegen), und große Logistiker mit komplexen VRP-Anforderungen (>100 Stopps, Multi-Depot), dafür ist die Optimization-API zu begrenzt, hier braucht es OR-Tools, jsprit oder kommerzielle VRP-Spezialisten.

Preise im Detail

Plan	Preis	Was du bekommst
Free	0 EUR	API-Key sofort verfügbar, typ. 2.000 Directions/Tag, 500 Isochrones/Tag, 500 Matrix/Tag, 100 Optimization/Tag, 40 Anfragen/Min., EU-Hosting, alle Endpunkte
Basic / Standard	ab ca. 200 EUR/Monat	Höhere Tageslimits, mehr parallele Anfragen, dedizierter Support, kommerzielle Nutzung freigegeben
Enterprise	Auf Anfrage	Individuelle Limits, SLA, dedizierte Instanz, AVV nach DSGVO, garantierte Verfügbarkeit
Self-Hosted	Kostenlos (Apache-2.0)	Vollständige Open-Source-Engine zum Eigenbetrieb, keine Limits, eigene Hardware-Kosten

Einordnung: Das Free-Tier ist erstaunlich großzügig und für Prototypen, MVP-Phasen sowie kleinere Produktiv-Use-Cases (z. B. ein Dispatch-Tool mit ca. 50 Touren/Tag und 40 Stopps) tatsächlich ausreichend. Der Sprung von Free auf bezahlte Pläne ist die ehrlichste Schwelle: Sobald du SLA brauchst oder die Limits sprengst, wird ein kostenpflichtiger Plan oder Self-Hosting unvermeidlich. Self-Hosting lohnt sich ab etwa 50.000 Anfragen/Tag oder wenn die Datenhoheit absolute Priorität hat (Verwaltung, Gesundheit). Wer im Free-Tier zu Produktion einsteigt, sollte vor dem Live-Gang auf einen bezahlten Plan oder die eigene Instanz wechseln, sonst wird die fehlende SLA bei der ersten Lastspitze zum Problem.

Stärken im Detail

Open Source unter Apache-2.0, vollständige Quelloffenheit. Anders als Google Maps oder Mapbox kannst du den gesamten Code lesen, auditieren und modifizieren. Für Behörden, Forschung und sicherheitskritische Anwendungen ist das ein entscheidender Faktor. Der Source liegt auf GitHub bei GIScience und wird aktiv gepflegt.

EU-Hosting standardmäßig. Die gehostete API läuft auf Servern in Heidelberg. Damit ist OpenRouteService eine der wenigen Routing-APIs, die ohne juristische Sonderverhandlungen DSGVO-konform einsetzbar sind. Für Branchen mit Berufsgeheimnis, Patientendaten oder öffentliche Auftraggeber ist das ein echter Hebel, du sparst dir mehrwöchige Compliance-Diskussionen, die bei US-Anbietern üblich sind.

HeiGIT als seriöser Träger. HeiGIT ist eine gemeinnützige GmbH, gegründet 2019, finanziert von der Klaus-Tschira-Stiftung und der Universität Heidelberg. Forschung zu OSM-Datenqualität, Disaster-Routing und ML-basierter Geodaten-Anreicherung läuft permanent. Das bedeutet: Die Engine wird wissenschaftlich weiterentwickelt, nicht nur kommerziell. Für Anwender bedeutet das eine seltene Kombination aus Produktqualität und akademischer Solidität.

Großzügiges Free-Tier. Mit typisch 2.000 Directions/Tag plus den anderen Endpunkten ist das Free-Tier deutlich generöser als die Pendants bei Mapbox (50 Routen/Monat kostenlos) oder TomTom (limitiert). Für viele KMU reicht das im Produktivbetrieb, wenn du bereit bist, ohne SLA zu fahren. Für Tests, MVP und kleine Serien-Anwendungen ist es ein No-Brainer.

Vehicle-Routing-Optimization out of the box. Der Optimization-Endpoint löst echte VRPs mit Zeitfenstern, Fahrzeugkapazitäten und Skill-Matching. Intern verwendet OpenRouteService den VROOM-Solver, einen ausgereiften Open-Source-Optimierer. Damit bekommst du Funktionalität, für die kommerzielle Anbieter wie OptimoRoute oder Routific 30–100 EUR pro Fahrer pro Monat verlangen, kostenlos im Free-Tier, wenn auch mit harten Grenzen (3 Fahrzeuge, 50 Routen pro Aufruf).

Isochronen für Standortanalysen. Die Isochronen-API berechnet “in 15 Minuten per PKW erreichbare Fläche” für jeden Punkt der Welt. Das ist die Grundlage für Einzugsgebiet-Analysen, Standortbewertungen, Außendienst-Gebietszuschnitte und Logistik-Optimierung. In Kombination mit BI-Tools wird daraus eine vollwertige Geomarketing-Lösung, zum Bruchteil der Kosten kommerzieller Anbieter wie Esri oder Microgeo.

Klare Verkehrsprofile. Auto, LKW (mit Gewicht und Höhenrestriktionen), Fahrrad (drei Varianten: Stadt, Rennrad, Mountainbike), Fußgänger, Wandern, Rollstuhl. Die Differenzierung ist tiefer als bei vielen Wettbewerbern und besonders das LKW-Routing mit Höhen- und Gewichtsbeschränkungen ist im Logistik-Kontext wertvoll.

Schwächen ehrlich betrachtet

OSM-Datenqualität variiert regional stark. OpenStreetMap ist crowd-sourced. In deutschen Großstädten und entlang von Autobahnen ist die Datenqualität exzellent, oft besser als Google Maps. In ländlichen Gebieten, Industriegeländen oder Neubaugebieten gibt es Lücken: fehlende Hausnummern, falsch klassifizierte Straßen, veraltete Einbahnregelungen. Für reine Stadt-Anwendungen kein Problem, für flächendeckende Außendienst-Routing-Lösungen musst du Stichproben fahren, bevor du produktiv gehst.

Kein Echtzeit-Verkehr. OpenRouteService kennt keine aktuellen Stauinformationen. Die Reisezeiten sind statische Durchschnittswerte, optional gewichtet mit Tageszeit-Profilen, aber kein Live-Traffic-Feed. Für tägliche Tourenplanung ist das oft okay (du planst die Tour morgens für den Tag), für minutengenaue ETA-Vorhersagen oder Notfall-Routing reicht das nicht. Google Maps Platform und TomTom bleiben hier deutlich überlegen.

Optimization-API ist im Free-Tier eng begrenzt. Drei Fahrzeuge pro Aufruf, 50 Routen pro Anfrage, das ist für viele reale Logistik-Probleme zu wenig. Für die Tourenplanung eines Reinigungsdiensts mit fünf Fahrern und 80 Objekten musst du das Problem zerlegen oder auf einen externen Solver wie Google OR-Tools wechseln. OpenRouteService liefert dann nur noch die Distanzmatrix.

Keine SLA im Free-Tier. Wenn die Heidelberger Server ausfallen, gibt es keine Service-Level-Garantie. Für unkritische Anwendungen okay, für produktive Dispositionssysteme musst du entweder auf einen kostenpflichtigen Plan wechseln oder Self-Hosting betreiben. Im Free-Tier ist OpenRouteService eine Ressource für gemeinsame Forschung und nicht-kritische Anwendungen, das ist transparent kommuniziert, aber muss bei der Architektur-Entscheidung berücksichtigt werden.

Dokumentation ist für Einsteiger zäh. Die API-Dokumentation ist vollständig, aber sprunghaft und teils auf Englisch, teils auf Deutsch. Einsteiger ohne API-Erfahrung brauchen länger, bis sie produktiv sind. Hilfreich ist das Python-SDK openrouteservice-py, das die häufigsten Aufgaben abstrahiert.

Self-Hosting hat hohe Einstiegshürden. Wer den globalen Graph selbst hosten will, braucht etwa 100 GB RAM allein für die Engine, weitere 200+ GB Festplatte für den OSM-Planet-Dump, und Geo-Daten-Know-how, um die Vorverarbeitung sauber aufzusetzen. Für einzelne Länder ist es deutlich leichter (Deutschland-Graph ca. 8 GB RAM), aber kein Plug-and-Play.

Keine KI im engeren Sinn. OpenRouteService ist ein algorithmisches Routing-Backend, Dijkstra, A*, Contraction Hierarchies, VROOM für VRP. Es ist keine KI-Anwendung, sondern ein klassisches Geo-Werkzeug. Das ist keine Schwäche, aber gut zu wissen: Die “KI” entsteht erst, wenn du das Routing-Backend mit einer Optimierungs- oder ML-Schicht kombinierst (z. B. Vorhersage von Servicezeiten je Objekt, Nachfrageprognose, Tour-Lernen aus Historie). HeiGIT selbst forscht aktiv an ML-Anreicherungen für OSM, aber das ist Forschung, nicht Produkt.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Echtzeit-Verkehr und garantierte SLA brauchst	Google Maps Platform oder TomTom (kommerziell)
Eine reine kommerzielle SaaS-Lösung mit guter Doku willst	Mapbox (kommerziell, ohne eigene Tool-Seite)
Workflows ohne Code orchestrieren und Routing nur als Baustein willst	oder
Komplexe VRP-Probleme mit >100 Stopps löst	Eigenes Setup mit OR-Tools oder kommerzielle VRP-Spezialisten

Erwähnenswert ohne eigene Tool-Seite: GraphHopper ist der direkte Open-Source-Konkurrent mit ähnlichem Funktionsumfang und kommerziellem SaaS-Angebot, ebenfalls aus Deutschland, mit klarem Logistik-Fokus und besser dokumentierter Optimization. Valhalla (Mapbox-Stiftung) ist technisch eine Alternative, aber weniger zugänglich. OSRM ist sehr schnell, hat aber keine Isochronen oder Optimization. HERE Maps und Esri ArcGIS Network Analyst sind die kommerziellen Schwergewichte, die mit OpenRouteService nichts gemeinsam haben außer der Funktionalität, Preise sind eine andere Liga. OpenRouteService bleibt für DSGVO-sensible Anwendungen mit überschaubarem Volumen die erste Wahl im deutschsprachigen Raum.

So steigst du ein

Schritt 1: API-Key holen und ersten Request stellen. Geh auf openrouteservice.org, registriere dich kostenlos (keine Kreditkarte nötig). Innerhalb von Sekunden bekommst du einen API-Schlüssel. Stelle einen ersten Test-Request gegen den Directions-Endpoint, z. B. von “Berlin Hauptbahnhof” zu “Hamburg Hauptbahnhof”, und prüfe das GeoJSON-Ergebnis. Wenn du Python nutzt, installier pip install openrouteservice und du bist in zehn Minuten produktiv.

Schritt 2: Use Case prototypisch bauen und mit Free-Tier validieren. Bevor du in produktive Architektur investierst, bau einen einfachen Prototypen: Lade deine zehn häufigsten Adressen, geocode sie über die Pelias-API, berechne die Distanzmatrix und prüfe die Routenqualität. Stichprobe gegen Google Maps, um Datenqualität zu beurteilen. Erst danach entscheiden: Reicht das Free-Tier produktiv? Brauchen wir einen Bezahlplan? Oder ist Self-Hosting der Weg?

Schritt 3: Architektur-Entscheidung treffen (gehostet vs. self-hosted). Bei <10.000 Anfragen/Tag und überschaubaren Datenschutzanforderungen: bezahlter Plan beim HeiGIT-Hosting. Bei >50.000 Anfragen/Tag oder strengster Datenhoheit (Verwaltung, Gesundheit, Verteidigung): Self-Hosting mit Docker-Compose und Region-spezifischem OSM-Dump. Plan etwa zwei Wochen für ein produktiv lauffähiges Self-Hosting ein, mehr für globale Abdeckung. HeiGIT veröffentlicht Docker-Images und Helm-Charts, die den Einstieg deutlich erleichtern.

Ein konkretes Beispiel

Ein Gebäudereiniger aus Stuttgart mit 45 Mitarbeitern und 120 Objekten plant seine Tagestouren bisher in Excel, 90 Minuten Aufwand pro Tag für die Disponentin, die unzufrieden ist, weil Touren regelmäßig suboptimal sind. Der CTO baut über zwei Wochenenden einen Prototypen: OpenRouteService liefert die Distanzmatrix zwischen allen 120 Objekten (einmal vorberechnet, ca. 14.400 Werte), eine selbstgeschriebene VRP-Heuristik (Greedy + 2-opt-Verbesserung) optimiert pro Tag die Reihenfolge unter Berücksichtigung der Zeitfenster und Mitarbeiterqualifikationen. Ergebnis: Die Disponentin pflegt nur noch Tagesänderungen, die Tourplanung läuft in 4 Minuten statt 90, die Fahrzeit pro Fahrer sinkt um 18 Prozent. Kosten: kostenlos im Free-Tier (~500 Anfragen/Tag), Entwicklungsaufwand etwa 30 Personenstunden. Amortisation: nach drei Wochen. Im sechsten Monat wechselt das Unternehmen auf den Basic-Plan (200 EUR/Monat) für SLA und höhere Limits, weil die Anwendung jetzt geschäftskritisch ist, immer noch ein Bruchteil der Kosten kommerzieller Tourenplanungs-Software (typisch 25–50 EUR pro Fahrer/Monat = 1.100–2.250 EUR/Monat für 45 Fahrer).

DSGVO & Datenschutz

• Datenhosting: Server in Heidelberg, Deutschland. Betreiber ist HeiGIT gGmbH, ein gemeinnütziges Institut der Universität Heidelberg. Damit unterliegt der Dienst vollständig deutschem und EU-Recht.
• Datennutzung: API-Anfragen (Start, Ziel, Routen-Anfragen) werden zur Bereitstellung des Dienstes verarbeitet. HeiGIT veröffentlicht aggregierte Nutzungsstatistiken zur Weiterentwicklung, keine Einzelanfragen oder Profilbildung.
• Personenbezogene Daten: Wer Adressen von Personen über die Geocoding-API verarbeitet (z. B. Kundenadressen), verarbeitet personenbezogene Daten im Sinne der DSGVO. Eine entsprechende Rechtsgrundlage und ggf. ein AVV mit HeiGIT sind nötig.
• Auftragsverarbeitung (AVV): Im Free-Tier nicht standardmäßig vorgesehen. Für kommerzielle und professionelle Nutzung empfiehlt sich der direkte Kontakt zu HeiGIT, AVV wird auf Anfrage abgeschlossen. Enterprise-Kunden bekommen einen vollwertigen AVV als Standardbestandteil.
• Datenhoheit beim Self-Hosting: Beim Eigenbetrieb verlassen keine Daten dein Rechenzentrum. Das ist für Verwaltung, Gesundheit und Verteidigung der entscheidende Hebel.
• Empfehlung für Unternehmen: Für unkritische Anwendungen ist die gehostete API ohne weitere Maßnahmen vertretbar. Für Branchen mit Berufsgeheimnis (Anwälte, Ärzte, Steuerberater) oder bei Verarbeitung von Patienten-/Mandantenadressen entweder AVV mit HeiGIT abschließen oder Self-Hosten.

Gut kombiniert mit

• , Workflow-Orchestrierung um den Routing-Endpoint herum. n8n holt Aufträge aus dem ERP, übergibt sie an OpenRouteService und schreibt die optimierten Touren zurück, ohne dass jemand Python schreiben muss. Im Self-Hosting-Setup bleibt alles in der EU.
• , Wenn du in einem No-Code-Stack arbeitest, kannst du OpenRouteService über HTTP-Calls aus Make heraus ansprechen. Praktisch für kleinere Außendienst-Routing-Workflows oder Standortanalysen, bei denen die Ausgabe an Google Sheets oder Airtable geht.
• , Eine sinnvolle Kombination, wenn die Routing-Ergebnisse in Berichte oder Präsentationen einfließen sollen. Der Routing-Backend liefert die Daten, Copilot fasst sie im gewohnten Office-Workflow zusammen.

Unser Testurteil

OpenRouteService verdient 4 von 5 Sternen. Es ist im deutschsprachigen Raum die mit Abstand sauberste Routing-API für DSGVO-sensible Anwendungen, Open Source, EU-Hosting, gemeinnütziger Träger, großzügiges Free-Tier. Der Funktionsumfang reicht für 80 Prozent aller realen Logistik- und Routing-Probleme aus, und für die anderen 20 Prozent lässt sich die Engine selbst hosten und beliebig erweitern. Den fünften Stern verliert OpenRouteService durch das Fehlen von Echtzeit-Verkehrsdaten, die enge Optimization-API im Free-Tier, regional schwankende OSM-Datenqualität und die fehlende SLA für unbezahlte Nutzer. Außerdem ist OpenRouteService strikt genommen keine KI-Anwendung, sondern ein algorithmisches Geo-Backend, die KI entsteht erst in der Schicht darüber. Für jeden, der KI-gestützte Tourenplanung in Deutschland baut und das Backend nicht selbst entwickeln möchte, ist OpenRouteService trotzdem der naheliegende Startpunkt. Praktische Empfehlung: Anfangen im Free-Tier, früh über bezahlten Plan oder Self-Hosting nachdenken, und die OSM-Datenqualität für die eigene Region einmal stichprobenweise prüfen, bevor produktiv gegangen wird.

Was wir bemerkt haben

• 2019, Gründung der HeiGIT gGmbH als gemeinnützige Trägerorganisation. Das wichtige Signal hinter dieser Strukturentscheidung: OpenRouteService ist kein Startup mit Exit-Druck, sondern ein Forschungsinstrument mit Stiftungsfinanzierung. Für Anwender bedeutet das deutlich höhere Wahrscheinlichkeit langfristiger Verfügbarkeit als bei VC-finanzierten Wettbewerbern.
• 2024, Version 8.0 mit deutlich verbesserter Infrastruktur veröffentlicht; gleichzeitig wurde die Disaster-Management-Sparte (Routing für humanitäre Einsätze) ausgebaut. Klarer Hinweis darauf, dass die Roadmap nicht nur kommerziell getrieben ist.
• 2024–2025, HeiGIT-Account und Pricing-Portal wurden auf eine neue Domain (account.heigit.org) konsolidiert. Wer alte Tutorials liest, findet teilweise Links, die auf 404 laufen, die Migration ist nicht überall sauber dokumentiert.
• Mai 2026, Free-Tier-Limits werden zwar nicht offiziell beworben, sind aber seit Jahren stabil bei rund 2.000 Directions/Tag, 500 Isochronen/Tag, 500 Matrix/Tag und 100 Optimization/Tag. Das ist im Branchenvergleich erstaunlich konstant, kommerzielle Wettbewerber haben Free-Tiers in den letzten zwei Jahren reihenweise gekürzt oder abgeschafft.
• Mai 2026, Eine Echtzeit-Verkehrs-Komponente fehlt weiterhin. Wer minutengenaue ETA-Vorhersagen mit Live-Traffic braucht, kommt um kommerzielle Anbieter (Google, TomTom, HERE) nicht herum, diese Lücke ist strukturell und nicht in der Roadmap angekündigt.