這是一場關於「空間數據」如何轉化為「人文地誌」的實驗。 WalkGIS:鄉鎮導航 在 WalkGIS 的開發過程中，我們面臨一個巨大的挑戰：台灣有 22 個縣市、368 個鄉鎮市區，總共 390 個行政單元。如果只是把邊界畫出來，那只是地圖；但如果要讓每個區塊都具備歷史、文化與生活感，那就是一項浩大的工程。 今天，我們完成了「鄉鎮導航」地圖的基礎設施建置。這不只是一張標記邊界的地圖，更是我們發展出的一套「行政區劃富化方法論」。 ...
影像豐富化之路：從雜訊清洗到 AI 自動化的 POI 補補完實錄 📸 前言：一張圖勝過千言萬語 在開發 WalkGIS 的過程中，我們發現一個「有溫度的點位」必須包含視覺元素。然而，當點位數量來到數百甚至上千個時，手動去一張張找圖、貼連結是不可能的任務。更具規戰性的是，原始資料中的點位名稱往往帶有大量管理雜訊（如「住-」、「推薦-」、「集章處－」），這些「髒資料」會讓搜尋引擎徹底失焦。 本文記錄了我們如何利用 AI 協作，從 0 到 1 打造出一套自動化的「POI 影像豐富化」流程，並將之封裝為一套可重複使用的技術 Skill。 🛠 演進工序：解決問題的三大步 1. 構建「階梯式」搜尋隊列 (Tiered Retrieval) 單一來源往往無法滿足多樣的地景需求。我們設計了一套「階梯式」策略： 第一層：Wikipedia PageImage API —— 針對權威性景點（如「台江國家公園」），直接抓取維基百科條目圖片，準確度最高。 第二層：Wikimedia Commons API —— 利用共享資源庫，透過多重名稱變體（如 File:{Name}, {Name} Taiwan）進行廣泛搜尋。 第三層：Google Places API (最強後援) —— 當開源資源都失效時，調用 Google Places Photo。這確保了即便是在山區的小型「工作站」或「民宿」，也能有高質量的實景照片。 2. 語意理解：LLM 驅動的名稱清洗 (Name Sanitization) 這是最核心的突破。面對 住-護照優惠-特富野民宿 這種名稱，傳統的正則表達式很難清乾淨。 LLM 預處理：我們讓 AI 批量讀取點位名稱，並產出「搜尋關鍵字陣列 (Array of Search Seeds)」。 映射機制：例如將 山海驛站-官田工作站 自動對應到 ["官田工作站", "農田水利署官田工作站"]。 規一化匹配：為了避免 mapping 時因為全半形符號（如 ｜ vs |）或多餘空白導致失敗，我們在腳本中實現了名稱規一化演算法。 3. 工程化與 Skill 化 為了讓這套邏輯不再只是「一次性腳本」，我們完成了以下優化： ...
從「靜態手冊」到「動態地圖」：山海圳國家綠道的數位敘事化轉型實錄 🌏 前言：數據的「生命力」 山海圳國家綠道（MTSW）是一條長達 177 公里的「溯源風土之河」。然而，長期以來這些珍貴的資訊分散在厚重的 PDF 手冊（112MB）與僅具備基本座標的 KMZ 檔案中。對於徒步者而言，在路途上翻閱 PDF 極其不便，而純粹的導航點又缺乏文史脈絡。 本文紀錄了利用 AI 協作，將山海圳從「靜態資料」轉型為「動態地圖系統」的完整工序。 WalkGIS:山海圳國家綠道 NotebookLM投影片 🛠 五大轉化階段 1. 骨架提取：從 KMZ 到空間索引 首先，我們解構了原始的 山海圳營運地圖.kmz。 斷開連結：在匯出時選擇不勾選「網路連結同步」，確保取得的是包含 109 個 POI 與 31 段軌跡（Tracks）的靜態座標資料。 空間格式化：將座標轉化為 WKT (Well-Known Text) 格式（如 POINT(...), LINESTRING(...)），這讓 AI 能在後續處理中理解地理位置。 2. 敘事賦能：批次化的「深度研究」 這是最具挑戰性的階段。109 個點位若逐一改寫，耗時緩慢。我們採取了「批次豐富化 (Batched Enrichment)」策略： AI 協調者模式：將 POI 分為「台江內海」、「大圳之路」、「原鄉之路」與「聖山之路」四個文化生活圈進行改寫。 內容增量：不只是複製手冊，而是透過 AI 挖掘歷史背景、加入在地美食推薦與實用的旅人筆記。這將原本冷冰冰的點位，轉化為具有「生活溫度」的內容。 3. 結構化轉置：Markdown 作為中繼 每個 POI 點位都被轉化為一個獨立的 Markdown 檔案。 YAML Frontmatter：包含類別、日期、座標與 WKT 等 metadata。 標準化資訊卡：在文末提供統一的 📬 資訊卡 區塊，方便系統讀取地址與聯絡電話。 4. 系統整合：WalkGIS 資料庫同步 透過 Python 腳本將上述 Markdown 資料與地圖邏輯匯入 WalkGIS (SQLite) 資料庫。 ...