{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["Physical AI"],"content":{"markdown":"Sobald eine Maschine eine Karte hat, kann sie planen. Eine Navigations-App, ein Lieferroboter und ein Robotaxi lösen täglich tausendfach dieselbe Grundaufgabe: die kürzeste Route von hier nach dort durch ein Netz aus Straßen oder Gängen finden. Das klingt einfach, doch eine Stadt hat Zehntausende Kreuzungen, und jede mögliche Route zu prüfen, würde ewig dauern. Die Verfahren, die das schnell lösen, gehören zu den ältesten und wichtigsten Algorithmen der Informatik.\n\nDies ist Teil 2 von Level 2 in unserem Lernpfad Physical AI. Wir haben das echte Straßennetz eines Teils von San Francisco, einer Stadt, in der Robotaxis zum Alltagsverkehr gehören, aus OpenStreetMap geladen und {{\u003c num \"route_planning\" \"rp_pairs\" \u003e}} zufällige Routen mit fünf verschiedenen Suchverfahren geplant. Sie erfahren, wie aus einem Stadtplan ein Graph wird, wie Dijkstras Algorithmus und A* ihn durchsuchen und warum die schnellsten Verfahren nicht immer die kürzeste Route finden.\n\n## Das Straßennetz als Graph\n\nFür einen Computer ist ein Stadtplan ein **Graph**: Kreuzungen und Knicke sind **Knoten**, die Straßenstücke dazwischen **Kanten**, und jede Kante hat ein **Gewicht**, hier ihre Länge in Metern. Unser Ausschnitt von San Francisco, von Downtown bis zur Mission, enthält {{\u003c num \"route_planning\" \"rp_nodes\" \u003e}} Knoten, die alle voneinander erreichbar sind, und {{\u003c num \"route_planning\" \"rp_road_km\" \u003e}} Kilometer Straße. {{\u003c num \"route_planning\" \"rp_oneway_pct\" \u003e}} % der Straßenstücke sind nur in einer Richtung befahrbar — das zwingt Routen in Umwege, die ein Fußgänger nicht bräuchte.\n\n| Begriff | Bedeutung | In unserer Karte |\n|---|---|---|\n| Knoten | Ein Punkt, an dem sich die Route ändern kann | Kreuzungen und Knicke |\n| Kante | Eine Verbindung zwischen zwei Knoten | Ein Straßenstück zwischen zwei Kreuzungen |\n| Gewicht | Was die Nutzung einer Kante kostet | Länge in Metern |\n| Einbahnkante | Eine Kante nur in einer Richtung | Fast die Hälfte aller Stücke |\n| Schätzung (Heuristik) | Eine Vermutung über die Restkosten | Luftlinie zum Ziel |\n\n## Dijkstra: Suche in alle Richtungen\n\n**Dijkstras Algorithmus**, 1959 veröffentlicht, arbeitet wie eine Welle, die sich vom Start ausbreitet. Er macht immer mit dem nächstgelegenen Knoten weiter, den er noch nicht abgeschlossen hat, und erreicht so jeden Knoten auf dem kürzestmöglichen Weg. Erreicht die Welle das Ziel, ist die Route garantiert die kürzeste. Der Haken: Die Welle breitet sich in alle Richtungen aus, auch vom Ziel weg.\n\n![Zwei Karten desselben Straßennetzes: links hat Dijkstras Suche Knoten in einem großen Kreis um den Start geprüft, der den Großteil der Karte bedeckt; rechts hat A* nur ein schmales Band von Knoten zwischen Start und Ziel geprüft; beide finden dieselbe Route](/images/learn/de/route-planning-dijkstra-astar-explored.webp \"Eine Route durch San Francisco: die Knoten, die jedes Verfahren prüfte, bevor es die kürzeste Route fand.\")\n\nFür unsere Routen von 1 bis 3 Kilometern prüfte Dijkstra im Median {{\u003c num \"route_planning\" \"rp_dijkstra_median\" \u003e}} Knoten, etwa zwei Drittel des ganzen Netzes. Auf der Beispielroute oben, {{\u003c num \"route_planning\" \"rp_ex_km\" \"2\" \u003e}} Kilometer lang bei {{\u003c num \"route_planning\" \"rp_ex_air_km\" \"2\" \u003e}} Kilometern Luftlinie, waren es {{\u003c num \"route_planning\" \"rp_ex_dijkstra\" \u003e}} Knoten.\n\n## A*: ein Gespür für die Richtung\n\n**A*** („A-Stern“) fügt ein Stück Wissen hinzu: eine Schätzung der restlichen Strecke. Wir nutzen die Luftlinie zum Ziel. A* macht immer mit dem Knoten weiter, bei dem bisherige Strecke plus Schätzung am kleinsten ist — die Suche neigt sich also zum Ziel. Solange die Schätzung die wahre Reststrecke nie überschätzt, und keine Straße ist kürzer als die Luftlinie, findet A* weiterhin die kürzeste Route.\n\nAuf unseren Routen prüfte A* im Median {{\u003c num \"route_planning\" \"rp_astar_median\" \u003e}} Knoten, im Mittel {{\u003c num \"route_planning\" \"rp_astar_saving_pct\" \u003e}} % weniger als Dijkstra, und fand jedes einzelne Mal die kürzeste Route. Auf der Beispielroute brauchte es nur {{\u003c num \"route_planning\" \"rp_ex_astar\" \u003e}} Knoten.\n\n## Schneller, aber nicht mehr die kürzeste\n\nNoch schneller wird A*, wenn man der Schätzung mehr vertraut. **Gewichtetes A*** multipliziert die Schätzung mit einem Faktor. Mit Faktor 3 prüfte die Suche im Median nur {{\u003c num \"route_planning\" \"rp_astar3_median\" \u003e}} Knoten, fand die kürzeste Route aber nur in {{\u003c num \"route_planning\" \"rp_astar3_optimal_pct\" \u003e}} % der Fälle, mit einem Umweg von im Mittel {{\u003c num \"route_planning\" \"rp_astar3_detour_pct\" \u003e}} %. Der Extremfall ist die **gierige Bestensuche**, die nur der Schätzung folgt und die schon gefahrene Strecke ignoriert. Sie war genauso schnell, im Median {{\u003c num \"route_planning\" \"rp_greedy_median\" \u003e}} Knoten, doch ihre Routen waren im Mittel {{\u003c num \"route_planning\" \"rp_greedy_detour_pct\" \u003e}} % länger und bis zu {{\u003c num \"route_planning\" \"rp_greedy_detour_max_pct\" \u003e}} %: Sie hält direkt aufs Ziel zu und kann dabei in Einbahnstraßen und Sackgassen geraten, die lange Umwege erzwingen.\n\n{{\u003c data \"route-algos\" \u003e}}\n\n![Zwei Balkendiagramme für fünf Suchverfahren: links die mittlere Zahl geprüfter Knoten, von etwa viertausend bei Dijkstra über deutlich unter tausend bei A* bis etwa hundert bei den schnellsten Verfahren; rechts der mittlere Umweg, null bei Dijkstra und A*, steigend beim gewichteten A* und am höchsten bei der gierigen Suche](/images/learn/de/route-planning-dijkstra-astar-tradeoff.webp \"Tempo gegen Qualität: Je weniger Knoten ein Verfahren prüft, desto länger werden tendenziell seine Routen.\")\n\n## Was echte Systeme ergänzen\n\nUnser Experiment zeigt den Kern der Routenplanung. Echte Systeme bauen auf mehrere Arten darauf auf:\n\n- **Zeit statt Strecke.** Navigation gewichtet Kanten nach erwarteter Fahrzeit, mit Tempolimits, Verkehr, Wartezeiten an Ampeln und den Mehrkosten von Linksabbiegern.\n- **Vorbereitung im Voraus.** Navigationsdienste bereiten ihre Straßennetze so vor, dass Routen quer über einen Kontinent in Millisekunden beantwortet werden; die Suche selbst prüft dann nur wenige Hundert Knoten.\n- **Schichten der Planung.** Ein Robotaxi plant zuerst die Route durch die Stadt, dann sein Verhalten, etwa wann es die Spur wechselt, und schließlich die genaue Bahn für die nächsten Sekunden, der die Regelung folgen muss.\n- **Neu planen.** Ist eine Straße gesperrt oder trifft ein Roboter auf ein Hindernis, wird der Plan neu berechnet — wenn nötig viele Male pro Minute.\n\n## So haben wir die Daten ausgewertet\n\nWir haben alle befahrbaren Straßen eines Ausschnitts von San Francisco aus OpenStreetMap geladen, Einbahnstraßen beachtet und nur den Teil des Netzes behalten, in dem jeder Knoten von jedem anderen erreichbar ist. Mit festem Zufallsstartwert haben wir {{\u003c num \"route_planning\" \"rp_pairs\" \u003e}} zufällige Start- und Zielpunkte mit 1 bis 3 Kilometern Luftlinie gezogen und alle fünf Verfahren auf jedes Paar angewendet. Wir zählen die Knoten, die ein Verfahren abgeschlossen hat — ein Maß, das nicht von der Geschwindigkeit des Rechners abhängt. Der nächste Teil folgt einer geplanten Route auf der Straße: Wie ein selbstfahrendes Auto entlang der Bahn lenkt.","text":"Sobald eine Maschine eine Karte hat, kann sie planen. Eine Navigations-App, ein Lieferroboter und ein Robotaxi lösen täglich tausendfach dieselbe Grundaufgabe: die kürzeste Route von hier nach dort durch ein Netz aus Straßen oder Gängen finden. Das klingt einfach, doch eine Stadt hat Zehntausende Kreuzungen, und jede mögliche Route zu prüfen, würde ewig dauern. Die Verfahren, die das schnell lösen, gehören zu den ältesten und wichtigsten Algorithmen der Informatik.\nDies ist Teil 2 von Level 2 in unserem Lernpfad Physical AI. Wir haben das echte Straßennetz eines Teils von San Francisco, einer Stadt, in der Robotaxis zum Alltagsverkehr gehören, aus OpenStreetMap geladen und 300 zufällige Routen mit fünf verschiedenen Suchverfahren geplant. Sie erfahren, wie aus einem Stadtplan ein Graph wird, wie Dijkstras Algorithmus und A* ihn durchsuchen und warum die schnellsten Verfahren nicht immer die kürzeste Route finden.\nDas Straßennetz als Graph Für einen Computer ist ein Stadtplan ein Graph: Kreuzungen und Knicke sind Knoten, die Straßenstücke dazwischen Kanten, und jede Kante hat ein Gewicht, hier ihre Länge in Metern. Unser Ausschnitt von San Francisco, von Downtown bis zur Mission, enthält 6.170 Knoten, die alle voneinander erreichbar sind, und 187 Kilometer Straße. 46,9 % der Straßenstücke sind nur in einer Richtung befahrbar — das zwingt Routen in Umwege, die ein Fußgänger nicht bräuchte.\nWie ein Roboter seine Route findet: Dijkstra und A* auf einer echten Karte Begriff Bedeutung In unserer Karte Knoten Ein Punkt, an dem sich die Route ändern kann Kreuzungen und Knicke Kante Eine Verbindung zwischen zwei Knoten Ein Straßenstück zwischen zwei Kreuzungen Gewicht Was die Nutzung einer Kante kostet Länge in Metern Einbahnkante Eine Kante nur in einer Richtung Fast die Hälfte aller Stücke Schätzung (Heuristik) Eine Vermutung über die Restkosten Luftlinie zum Ziel Dijkstra: Suche in alle Richtungen Dijkstras Algorithmus, 1959 veröffentlicht, arbeitet wie eine Welle, die sich vom Start ausbreitet. Er macht immer mit dem nächstgelegenen Knoten weiter, den er noch nicht abgeschlossen hat, und erreicht so jeden Knoten auf dem kürzestmöglichen Weg. Erreicht die Welle das Ziel, ist die Route garantiert die kürzeste. Der Haken: Die Welle breitet sich in alle Richtungen aus, auch vom Ziel weg.\nEine Route durch San Francisco: die Knoten, die jedes Verfahren prüfte, bevor es die kürzeste Route fand. Für unsere Routen von 1 bis 3 Kilometern prüfte Dijkstra im Median 4.132 Knoten, etwa zwei Drittel des ganzen Netzes. Auf der Beispielroute oben, 2,60 Kilometer lang bei 2,38 Kilometern Luftlinie, waren es 4.992 Knoten.\nA*: ein Gespür für die Richtung A* („A-Stern“) fügt ein Stück Wissen hinzu: eine Schätzung der restlichen Strecke. Wir nutzen die Luftlinie zum Ziel. A* macht immer mit dem Knoten weiter, bei dem bisherige Strecke plus Schätzung am kleinsten ist — die Suche neigt sich also zum Ziel. Solange die Schätzung die wahre Reststrecke nie überschätzt, und keine Straße ist kürzer als die Luftlinie, findet A* weiterhin die kürzeste Route.\nAuf unseren Routen prüfte A* im Median 816 Knoten, im Mittel 76,4 % weniger als Dijkstra, und fand jedes einzelne Mal die kürzeste Route. Auf der Beispielroute brauchte es nur 352 Knoten.\nSchneller, aber nicht mehr die kürzeste Noch schneller wird A*, wenn man der Schätzung mehr vertraut. Gewichtetes A* multipliziert die Schätzung mit einem Faktor. Mit Faktor 3 prüfte die Suche im Median nur 133 Knoten, fand die kürzeste Route aber nur in 12,3 % der Fälle, mit einem Umweg von im Mittel 6,3 %. Der Extremfall ist die gierige Bestensuche, die nur der Schätzung folgt und die schon gefahrene Strecke ignoriert. Sie war genauso schnell, im Median 133 Knoten, doch ihre Routen waren im Mittel 11,7 % länger und bis zu 67,9 %: Sie hält direkt aufs Ziel zu und kann dabei in Einbahnstraßen und Sackgassen geraten, die lange Umwege erzwingen.\nFünf Suchverfahren auf denselben Routen VerfahrenGeprüfte Knoten (Median)Kürzeste Route gefundenUmweg im MittelGrößter Umweg Dijkstra4.132100,0 %0,0 %0,0 % A* (Luftlinie als Schätzung)816100,0 %0,0 %0,0 % Gewichtetes A* (Faktor 1,5)16816,7 %3,0 %25,0 % Gewichtetes A* (Faktor 3)13312,3 %6,3 %40,3 % Gierige Bestensuche1337,7 %11,7 %67,9 % Quelle wie bei der ersten Tabelle dieser Seite.\nTempo gegen Qualität: Je weniger Knoten ein Verfahren prüft, desto länger werden tendenziell seine Routen. Was echte Systeme ergänzen Unser Experiment zeigt den Kern der Routenplanung. Echte Systeme bauen auf mehrere Arten darauf auf:\nZeit statt Strecke. Navigation gewichtet Kanten nach erwarteter Fahrzeit, mit Tempolimits, Verkehr, Wartezeiten an Ampeln und den Mehrkosten von Linksabbiegern. Vorbereitung im Voraus. Navigationsdienste bereiten ihre Straßennetze so vor, dass Routen quer über einen Kontinent in Millisekunden beantwortet werden; die Suche selbst prüft dann nur wenige Hundert Knoten. Schichten der Planung. Ein Robotaxi plant zuerst die Route durch die Stadt, dann sein Verhalten, etwa wann es die Spur wechselt, und schließlich die genaue Bahn für die nächsten Sekunden, der die Regelung folgen muss. Neu planen. Ist eine Straße gesperrt oder trifft ein Roboter auf ein Hindernis, wird der Plan neu berechnet — wenn nötig viele Male pro Minute. So haben wir die Daten ausgewertet Wir haben alle befahrbaren Straßen eines Ausschnitts von San Francisco aus OpenStreetMap geladen, Einbahnstraßen beachtet und nur den Teil des Netzes behalten, in dem jeder Knoten von jedem anderen erreichbar ist. Mit festem Zufallsstartwert haben wir 300 zufällige Start- und Zielpunkte mit 1 bis 3 Kilometern Luftlinie gezogen und alle fünf Verfahren auf jedes Paar angewendet. Wir zählen die Knoten, die ein Verfahren abgeschlossen hat — ein Maß, das nicht von der Geschwindigkeit des Rechners abhängt. Der nächste Teil folgt einer geplanten Route auf der Straße: Wie ein selbstfahrendes Auto entlang der Bahn lenkt.\n","words":911},"date":"2026-10-18","description":"Wie Navigationssysteme und Roboter die kürzeste Route finden, getestet am echten Straßennetz von San Francisco: warum A* weit weniger Orte prüft als Dijkstra.","image":"https://abxk.ai/images/cover/route-planning-dijkstra-astar.webp","json":"https://abxk.ai/de/physical-ai/learn/route-planning-dijkstra-astar/index.json","kind":"page","language":"de","learning_path":{"category":"physical-ai","level":2,"level_name":"Fortgeschritten"},"modified":"2026-10-18","section":"physical-ai","seo_title":"Routenplanung erklärt: Dijkstra und A* auf echter Karte","tags":["routenplanung","a-stern","dijkstra","openstreetmap","autonomes-fahren"],"title":"Wie ein Roboter seine Route findet: Dijkstra und A* auf einer echten Karte","translations":[{"json":"https://abxk.ai/en/physical-ai/learn/route-planning-dijkstra-astar/index.json","language":"en","url":"https://abxk.ai/en/physical-ai/learn/route-planning-dijkstra-astar/"}],"url":"https://abxk.ai/de/physical-ai/learn/route-planning-dijkstra-astar/"}