{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["Physical AI"],"content":{"markdown":"Once a machine has a map, it can plan. A navigation app, a delivery robot and a robotaxi all solve the same basic task thousands of times a day: find the shortest route from here to there through a network of streets or corridors. The task sounds simple, but a city has tens of thousands of intersections, and checking every possible route would take forever. The methods that solve it quickly are some of the oldest and most important algorithms in computing.\n\nThis is part 2 of Level 2 in our learning path Physical AI. We took the real street network of a part of San Francisco, a city where robotaxis are part of everyday traffic, from OpenStreetMap and planned {{\u003c num \"route_planning\" \"rp_pairs\" \u003e}} random routes with five different search methods. You will learn how a street map becomes a graph, how Dijkstra's algorithm and A* search it and why the fastest methods do not always find the shortest route.\n\n## The street network as a graph\n\nFor a computer, a street map is a **graph**: intersections and bends are **nodes**, the road segments between them are **edges**, and each edge has a **weight**, here its length in meters. Our section of San Francisco, from Downtown to the Mission, contains {{\u003c num \"route_planning\" \"rp_nodes\" \u003e}} nodes that are all reachable from each other and {{\u003c num \"route_planning\" \"rp_road_km\" \u003e}} kilometers of road. {{\u003c num \"route_planning\" \"rp_oneway_pct\" \u003e}}% of the road segments can only be driven in one direction, which forces routes into detours that a pedestrian would not need.\n\n| Term | What it means | In our map |\n|---|---|---|\n| Node | A point where the route can change | Intersections and bends |\n| Edge | A connection between two nodes | A road segment between two intersections |\n| Weight | The cost of using an edge | Length in meters |\n| One-way edge | An edge in only one direction | Almost half of all segments |\n| Estimate (heuristic) | A guess of the remaining cost | Straight-line distance to the goal |\n\n## Dijkstra: searching in every direction\n\n**Dijkstra's algorithm**, published in 1959, works like a wave spreading from the start. It always continues with the closest node it has not finished yet, so it reaches every node on the shortest possible way. When the wave reaches the goal, the route is guaranteed to be the shortest. The catch: the wave spreads in every direction, also away from the goal.\n\n![Two maps of the same street network: on the left, Dijkstra's search has checked nodes in a large circle around the start, covering most of the map; on the right, A* has checked only a narrow band of nodes between start and goal; both find the same route](/images/learn/en/route-planning-dijkstra-astar-explored.webp \"One route through San Francisco: the nodes each method checked before it found the shortest route.\")\n\nFor our routes of 1 to 3 kilometers, Dijkstra checked {{\u003c num \"route_planning\" \"rp_dijkstra_median\" \u003e}} nodes in the median, about two thirds of the whole network. On the example route above, {{\u003c num \"route_planning\" \"rp_ex_km\" \"2\" \u003e}} kilometers long for a straight-line distance of {{\u003c num \"route_planning\" \"rp_ex_air_km\" \"2\" \u003e}} kilometers, it checked {{\u003c num \"route_planning\" \"rp_ex_dijkstra\" \u003e}} nodes.\n\n## A*: a sense of direction\n\n**A*** (pronounced \"A star\") adds one piece of knowledge: an estimate of the remaining distance. We use the straight-line distance to the goal. A* always continues with the node where the distance so far plus the estimate is smallest, so the search leans toward the goal. As long as the estimate never overestimates the true remaining distance, and no street is shorter than the straight line, A* still finds the shortest route.\n\nOn our routes, A* checked {{\u003c num \"route_planning\" \"rp_astar_median\" \u003e}} nodes in the median, {{\u003c num \"route_planning\" \"rp_astar_saving_pct\" \u003e}}% fewer than Dijkstra on average, and it found the shortest route every single time. On the example route, it needed only {{\u003c num \"route_planning\" \"rp_ex_astar\" \u003e}} nodes.\n\n## Faster, but no longer the shortest\n\nYou can make A* even faster by trusting the estimate more. **Weighted A*** multiplies the estimate by a factor. With a factor of 3, the search checked only {{\u003c num \"route_planning\" \"rp_astar3_median\" \u003e}} nodes in the median, but it found the shortest route in only {{\u003c num \"route_planning\" \"rp_astar3_optimal_pct\" \u003e}}% of the cases, with an average detour of {{\u003c num \"route_planning\" \"rp_astar3_detour_pct\" \u003e}}%. The extreme case is **greedy best-first search**, which only follows the estimate and ignores the distance already traveled. It was just as fast, {{\u003c num \"route_planning\" \"rp_greedy_median\" \u003e}} nodes in the median, but its routes were {{\u003c num \"route_planning\" \"rp_greedy_detour_pct\" \u003e}}% longer on average and up to {{\u003c num \"route_planning\" \"rp_greedy_detour_max_pct\" \u003e}}% longer: it heads straight for the goal and can run into one-way streets and dead ends that force long detours.\n\n{{\u003c data \"route-algos\" \u003e}}\n\n![Two bar charts for five search methods: on the left, the median number of nodes checked, from about four thousand for Dijkstra to well under a thousand for A* and about one hundred for the fastest methods; on the right, the average detour, zero for Dijkstra and A*, rising for weighted A* and highest for greedy search](/images/learn/en/route-planning-dijkstra-astar-tradeoff.webp \"Speed against quality: the fewer nodes a method checks, the longer its routes tend to be.\")\n\n## What real systems add\n\nOur experiment shows the core of route planning. Real systems build on it in several ways:\n\n- **Time instead of distance.** Navigation weighs edges by expected travel time, with speed limits, traffic, waiting times at lights and the extra cost of left turns.\n- **Preparation in advance.** Navigation services prepare their road networks so that routes across a whole continent can be answered in milliseconds; the search itself then checks only a few hundred nodes.\n- **Layers of planning.** A robotaxi plans the route through the city first, then its behavior, such as when to change lanes, and finally the exact trajectory for the next few seconds, which the controller has to follow.\n- **Planning again.** When a street is blocked or a robot meets an obstacle, the plan is recomputed, many times per minute if needed.\n\n## How we analyzed the data\n\nWe downloaded all drivable streets in a section of San Francisco from OpenStreetMap, respected one-way streets and kept only the part of the network in which every node can be reached from every other. We drew {{\u003c num \"route_planning\" \"rp_pairs\" \u003e}} random start and goal points with a straight-line distance of 1 to 3 kilometers, using a fixed random seed, and ran all five methods on every pair. We count the nodes a method has finished, a measure that does not depend on the speed of the computer. The next part follows a planned route on the road: how a self-driving car steers along it.","text":"Once a machine has a map, it can plan. A navigation app, a delivery robot and a robotaxi all solve the same basic task thousands of times a day: find the shortest route from here to there through a network of streets or corridors. The task sounds simple, but a city has tens of thousands of intersections, and checking every possible route would take forever. The methods that solve it quickly are some of the oldest and most important algorithms in computing.\nThis is part 2 of Level 2 in our learning path Physical AI. We took the real street network of a part of San Francisco, a city where robotaxis are part of everyday traffic, from OpenStreetMap and planned 300 random routes with five different search methods. You will learn how a street map becomes a graph, how Dijkstra\u0026rsquo;s algorithm and A* search it and why the fastest methods do not always find the shortest route.\nThe street network as a graph For a computer, a street map is a graph: intersections and bends are nodes, the road segments between them are edges, and each edge has a weight, here its length in meters. Our section of San Francisco, from Downtown to the Mission, contains 6,170 nodes that are all reachable from each other and 187 kilometers of road. 46.9% of the road segments can only be driven in one direction, which forces routes into detours that a pedestrian would not need.\nHow a Robot Finds Its Route: Dijkstra and A* on a Real Street Map Term What it means In our map Node A point where the route can change Intersections and bends Edge A connection between two nodes A road segment between two intersections Weight The cost of using an edge Length in meters One-way edge An edge in only one direction Almost half of all segments Estimate (heuristic) A guess of the remaining cost Straight-line distance to the goal Dijkstra: searching in every direction Dijkstra\u0026rsquo;s algorithm, published in 1959, works like a wave spreading from the start. It always continues with the closest node it has not finished yet, so it reaches every node on the shortest possible way. When the wave reaches the goal, the route is guaranteed to be the shortest. The catch: the wave spreads in every direction, also away from the goal.\nOne route through San Francisco: the nodes each method checked before it found the shortest route. For our routes of 1 to 3 kilometers, Dijkstra checked 4,132 nodes in the median, about two thirds of the whole network. On the example route above, 2.60 kilometers long for a straight-line distance of 2.38 kilometers, it checked 4,992 nodes.\nA*: a sense of direction A* (pronounced \u0026ldquo;A star\u0026rdquo;) adds one piece of knowledge: an estimate of the remaining distance. We use the straight-line distance to the goal. A* always continues with the node where the distance so far plus the estimate is smallest, so the search leans toward the goal. As long as the estimate never overestimates the true remaining distance, and no street is shorter than the straight line, A* still finds the shortest route.\nOn our routes, A* checked 816 nodes in the median, 76.4% fewer than Dijkstra on average, and it found the shortest route every single time. On the example route, it needed only 352 nodes.\nFaster, but no longer the shortest You can make A* even faster by trusting the estimate more. Weighted A* multiplies the estimate by a factor. With a factor of 3, the search checked only 133 nodes in the median, but it found the shortest route in only 12.3% of the cases, with an average detour of 6.3%. The extreme case is greedy best-first search, which only follows the estimate and ignores the distance already traveled. It was just as fast, 133 nodes in the median, but its routes were 11.7% longer on average and up to 67.9% longer: it heads straight for the goal and can run into one-way streets and dead ends that force long detours.\nFive search methods on the same routes MethodNodes checked (median)Shortest route foundAverage detourLargest detour Dijkstra4,132100.0%0.0%0.0% A* (straight line as estimate)816100.0%0.0%0.0% Weighted A* (factor 1.5)16816.7%3.0%25.0% Weighted A* (factor 3)13312.3%6.3%40.3% Greedy best-first search1337.7%11.7%67.9% Source as for the first table on this page.\nSpeed against quality: the fewer nodes a method checks, the longer its routes tend to be. What real systems add Our experiment shows the core of route planning. Real systems build on it in several ways:\nTime instead of distance. Navigation weighs edges by expected travel time, with speed limits, traffic, waiting times at lights and the extra cost of left turns. Preparation in advance. Navigation services prepare their road networks so that routes across a whole continent can be answered in milliseconds; the search itself then checks only a few hundred nodes. Layers of planning. A robotaxi plans the route through the city first, then its behavior, such as when to change lanes, and finally the exact trajectory for the next few seconds, which the controller has to follow. Planning again. When a street is blocked or a robot meets an obstacle, the plan is recomputed, many times per minute if needed. How we analyzed the data We downloaded all drivable streets in a section of San Francisco from OpenStreetMap, respected one-way streets and kept only the part of the network in which every node can be reached from every other. We drew 300 random start and goal points with a straight-line distance of 1 to 3 kilometers, using a fixed random seed, and ran all five methods on every pair. We count the nodes a method has finished, a measure that does not depend on the speed of the computer. The next part follows a planned route on the road: how a self-driving car steers along it.\n","words":974},"date":"2026-10-18","description":"How navigation systems and robots find the shortest route, tested on the real street network of San Francisco: why A* checks far fewer places than Dijkstra.","image":"https://abxk.ai/images/cover/route-planning-dijkstra-astar.webp","json":"https://abxk.ai/en/physical-ai/learn/route-planning-dijkstra-astar/index.json","kind":"page","language":"en","learning_path":{"category":"physical-ai","level":2,"level_name":"Intermediate"},"modified":"2026-10-18","section":"physical-ai","seo_title":"Route Planning Explained: Dijkstra and A* on a Real Map","tags":["route-planning","a-star","dijkstra","openstreetmap","self-driving"],"title":"How a Robot Finds Its Route: Dijkstra and A* on a Real Street Map","translations":[{"json":"https://abxk.ai/de/physical-ai/learn/route-planning-dijkstra-astar/index.json","language":"de","url":"https://abxk.ai/de/physical-ai/learn/route-planning-dijkstra-astar/"}],"url":"https://abxk.ai/en/physical-ai/learn/route-planning-dijkstra-astar/"}