Dijkstra Map 真實地圖路徑規劃系統架構書

本專案利用純前端技術與非同步計算，打造一個具備流暢互動體驗、即時演算法動畫，且直接整合真實世界地圖資料的 Dijkstra 最短路徑視覺化系統。

系統整體架構圖

核心技術組件說明

1. 地圖渲染與互動底層：Leaflet

• 定位：開源且輕量化的行動裝置友善互動式地圖底層庫。

• 優勢：

  • 極佳的圖層管控與 Marker 互動能力。
  • 支援深色調（Dark theme）地圖樣式配置，與自訂起終點圖標（Custom Icons），能完美融入現代化儀表板視覺風格。

2. 資料來源與網路拓撲：OpenStreetMap & Overpass API

• 定位：負責即時抓取真實世界的道路網路，並將其轉換為演算法所需的圖（Graph）結構。

• 開發動機：

  • 說明：傳統的演算法視覺化工具大多侷限在死板的「網格（Grid）」或自定義的點對點圖形上，缺乏實用感。為了打造一個能真正運算「真實道路」的路徑規劃工具，決定揚棄死板網格，直接串接地理資訊資料。透過 Overpass API 根據地圖視窗範圍（Bounding Box）動態獲取道路資料，大幅提升專案的趣味性與工程挑戰度。

3. 非同步計算核心：Web Workers

• 定位：系統的運算中樞，負責將複雜的路徑搜尋演算法移出主執行緒。

• 優勢：

  • 避免 UI 凍結：Dijkstra 演算法在處理真實世界成千上萬個節點與邊時，運算量極大。透過 Web Worker 在背景處理計算，確保地圖拖曳、放大縮小等使用者介面（UI）操作依然維持 60fps 。
  • 即時動畫抽稀：計算過程中能非同步傳回「當前探測節點」，供主執行緒動態渲染搜尋擴散動畫。

開發踩坑筆記 (Troubleshooting)

⚠️ 從 Python 後端 (OSMnx + NetworkX) 轉型純前端的架構陣痛

• 問題描述： 專案初期本來規劃使用 Python 的 OSMnx 和 NetworkX 來搭建後端 API 負責計算與動畫生成。然而實測發現，每次使用者調整起終點，封包在「前端發送 -> 後端下載 OSM 拓撲 -> 後端計算 -> 序列化回傳 -> 前端解包渲染」的過程中，產生嚴重的網路延遲與伺服器運算負載，且難以做到流暢的「即時擴散動畫」。
• 目前解法： 決定大膽砍掉後端，將架構完全重構成純前端（Pure Frontend）。直接在前端瀏覽器下載經由 Overpass API 過濾後的輕量化道路資料，並將數據結構格式化為鄰接清單（Adjacency List），直接交由 Web Worker 進行本地計算。雖然增加了前端首次載入資料的負擔，但換來的是完全不卡頓的互動路徑計算與零伺服器維護成本。

為什麼選擇這個架構？

• 零伺服器成本（Serverless）：完全基於靜態網頁架構（純前端），程式碼可直接託管於 GitHub Pages 等平台，不需負擔任何雲端主機運算費用。
• 極致的使用者體驗：得益於 Web Worker 的多執行緒處理，複雜的圖形演算法與繁重渲染被完全隔離，徹底告別網頁假死與畫面焦慮。
• 貼近真實應用的工程實踐：跳脫課本的點對點操作，真正處理了地理資訊系統（GIS）中經緯度轉換、道路權重計算與圖結構封裝，極具技術展示價值。