在構建「WalkGIS —— 全台散步地圖」專案的過程中，我與 AI Agent (Antigravity) 進行了一場深度的架構辯論。核心問題在於：當我們希望 AI 能像人類一樣理解地圖時，傳統的 GIS 資料庫還是最好的選擇嗎？
這篇文章記錄了我們如何從傳統的 SpatiaLite 方案，轉向一個更輕量、更適合 LLM 的 “Text-based GIS” 架構。
1. 痛點：AI 讀不懂二進位碼 (Binary Blob)
起初，我們理所當然地選擇了 SpatiaLite 作為 SQLite 的空間擴充。它是業界標準，功能強大。但是，當我嘗試讓 Agent 讀取資料庫時，問題出現了：
Agent: “我讀取到了
geometry欄位，但它是 binary blob，我無法直接解析它的座標。”
SpatiaLite 為了效能，將幾何資料存為二進位格式。這對 QGIS 很好，但對 LLM 來說，就像是一本無字天書。如果要讓 Agent 理解「后里馬場在哪裡？」，我們必須寫額外的 Python 程式碼去解碼它，這增加了依賴度與複雜性。
2. 決策：擁抱 WKT (AI-First Approach)
既然我們的目標是 “Agentic GIS”，為什麼不直接存成文字呢？ 於是，我們做了一個大膽的決定：棄用 SpatiaLite，擁抱 WKT (Well-Known Text)。
我們將 DB Schema 修改如下：
CREATE TABLE walking_map_features (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
-- geometry BLOB, <-- 傳統做法 (X)
geometry_wkt TEXT NOT NULL -- 新做法 (O) : POINT(120.735 24.298)
);
這個改變帶來的紅利是巨大的：
- AI 原生可讀：LLM 可以直接看懂
POINT(120.7 24.2)，甚至能直接生成 SQL 進行空間查詢（雖然不如 PostGIS 精確，但對散步地圖足夠了）。 - 零依賴 (Zero-Dependency)：任何支援 SQLite 的環境都能跑，不需要由複雜的 C++ GIS Libraries 支援。
- MCP 友善：透過 Model Context Protocol 傳輸 JSON 時，文字格式無縫接軌。
3. 創新：用 Mermaid 畫地圖
解決了「幾何 (Geometry)」問題，下一個挑戰是「拓樸 (Topology)」。 散步地圖往往不是單純的點，而是有順序的「路線」。傳統 GIS 用 LineString 來畫線，但它無法表達 “流程” 與 “邏輯”。
我們引入了 Mermaid Flowchart 作為地圖的邏輯描述語言，存放在 meta_data 中：
graph LR;
%% 子圖：后豐鐵馬道
subgraph Houfeng ["后豐鐵馬道 (4.5km)"]
direction TB
H1(1. 后里馬場) --> HA(樟樹平台);
HA --> H2(2. 夫妻樹);
H2 --> H3(3. 九號隧道);
H3 --> H4(4. 花樑鋼橋);
H4 --> HB(鐵道之鄉酒莊);
HB -.-> HC(榮町雜貨店);
end
%% 子圖：東豐綠廊 (前段)
subgraph Dongfeng_Start ["東豐綠廊-起點段"]
D7(7. 豐原大道) --> Junction{綠廊交接處};
HB --> Junction;
Junction --> D5(5. 朴口車站);
D5 --> HE(200days冰店);
HE --> D6(6. 豐榮水利碑);
end
%% 子圖：石岡精華段與東勢段 (簡略)
subgraph Shigang ["石岡精華..."]
D6 --> D9(9. 石岡水壩);
D9 --> D14(14. 情人木橋);
D14 --> D19(19. 東勢客家園區);
end
classDef highlight fill:#fcf,stroke:#f00;
class H1,H3,H4,D9,D19 highlight;
這讓 WalkGIS 不僅能告訴你東西在哪 (Where)，還能告訴你怎麼走 (How)。
4. 實戰：24 個景點的自動化匯入
有了架構，我們利用一張「后豐鐵馬道導覽圖」進行了壓力測試。 透過一個 Python 腳本，結合 AI 的視覺辨識與網路搜尋能力，我們在幾分鐘內就建立了包含 24 個景點、一條 Y 字型複雜路線的完整資料庫。
5. 結語
WalkGIS V0.1 的誕生證明了，在 AI 時代，「可讀性 (Readability)」可能比「儲存效率 (Efficiency)」更重要。透過 WKT 與 Mermaid，我們打破了 GIS 與 LLM 之間的隔閡，讓地圖資料庫成為了一個 AI 隨時可以閱讀、理解並協作的故事書。
6. 成果展示 (Gallery & Data Preview)
為了驗證架構的可行性，我們實際匯入了 24 個景點並建立了第一張地圖。以下是目前的系統狀態快照：
6.1 QGIS 視覺化成果
透過 Virtual Layer 連接 walkgis.db，我們成功在 QGIS 地圖上渲染出所有景點 (Point) 與其屬性。
6.2 真實地圖對照
我們使用的底圖來源，與數位化後的資料呈現高度一致。
6.3 資料庫實體預覽
walkgis.db 目前的檔案狀態與 Schema 結構。
Feature 範例 (Row Data)
這是 “后里馬場” 在資料庫中的真實樣貌。注意到 geometry_wkt 是人類可讀的文字，且 meta_data 指向了外部的 Markdown 文件。
{
"feature_id": "20251229_houli_ranch",
"name": "后里馬場",
"description": "后豐鐵馬道起點，歷史悠久的馬場。",
"geometry_type": "Point",
"geometry_wkt": "POINT(120.73582 24.298637)",
"meta_data": {
"ref_doc": "features/20251229_houli_ranch.md",
"generated_by": "batch_import"
}
}
Map 範例 (Row Data)
這是 “后豐東豐大環線” 的地圖定義。最精彩的部分在於 routes 欄位中儲存了完整的 Mermaid 拓樸邏輯。
{
"map_id": "2025_houfeng_dongfeng_loop",
"name": "后豐鐵馬道 & 東豐綠廊精華遊",
"meta_data": {
"difficulty": "Easy",
"total_distance": "18km",
"routes": {
"main_route": "graph LR; subgraph Houfeng [\"后豐鐵馬道\"]; H1(1. 后里馬場) --> HA(樟樹平台); HA --> H2(2. 夫妻樹); H2 --> H3(3. 九號隧道); H3 --> H4(4. 花樑鋼橋); end; subgraph Dongfeng [\"東豐綠廊\"]; H4 --> Junction{交會點}; Junction --> D5(5. 朴口車站); D5 --> D9(9. 石岡水壩); D9 --> D14(14. 情人木橋); D14 --> D19(19. 東勢客家園區); end; class H1,H3,H4,D9,D19 highlight;"
}
}
}
AI 協作宣告 (AI Collaboration Disclosure)
本文內容由 AI 協作生成：
- 素材來源：WalkGIS 專案實作與資料。
- 文章生成：Antigravity 協助撰寫技術筆記與釋出公告。
- 文章落地：Antigravity 協助排版與發布。
