SQLite

上一篇我們用 Python 打造了能解讀歷史座標的「時光羅盤」。但羅盤只會告訴你地名，無法告訴你歷史。真正的歷史，藏在文言文的汪洋大海中。 因為我本身對台灣史完全沒有概念，為了建立自己的知識體系，我首先向 AI 提問，得到了這份極具啟發性的「台灣方志演化樹」： 【根】 全域性/起源 (Early & Comprehensive) ║ ╚══ 1684《福建通志‧臺灣府》(清代最早的官方紀錄) ║ ╠══ 1694《臺灣府志》(確立台灣史志的基本架構) ║ ╠══ 1920《臺灣通史》(連橫著，民間史學集大成之作) ║ ╚══【幹】 區域行政中心 (以北台灣為例) ║ ╚══ 1871《淡水廳志》(新竹史料之源，具行政與大租分配紀載) ║ ╠══【枝】 縣級史志 (新竹設縣後) ║ ║ ║ ╠══ 1892《新竹縣志初稿》(新竹正式設縣後的首部地方志) ║ ║ ║ ╠══ 1895《新竹縣制度考》(日治初期清理清代制度之專作) ║ ║ ║ ╚══ 1907《新竹廳志》(結合日治調查與清代舊志) ║ ╚══【葉】 地方/微觀採訪 (Local & Micro-geographic) ║ ╠══ 1894《新竹縣採訪冊》(最細微的點位紀錄，如黃金洞、御史崎) ║ ╠══ 1898《樹杞林志》(專注於新竹東部山區與竹東拓墾) ║ ╚══ 1980+《新竹縣/市志》(現代修訂版本) 有了這張圖，我就知道該去哪裡尋寶了。於是，我花了一點時間想辦法把這些史書從網路上抓了下來（大部分都順利搞定了）。 ...

首席架構師開發日誌：揭秘 V2 升級如何透過 DataSourceContext 實現從「內容網站」到「通用瀏覽器」的範式轉移，以及如何解決 WASM 重啟與跨域資源映射的技術挑戰。

揭秘如何利用 SQLite WebAssembly 與靜態網頁技術，以零後端成本打造高效能的 GIS 應用程式，實現資料庫前端查詢與 Markdown 動態載入的混合架構。

驗證 WalkGIS 系統的擴充性：透過標準化流程，快速部署「大甲溪水利溯源」與「智慧水圳」兩條全新路線，並整合 Google Maps 導航與 AI 內容生成。

如何將生硬的 GIS 數據變成生動的旅遊故事？本文分享我的 WalkGIS 自動化工作流：使用 Shell Script 從 SQLite 精準萃取地圖資料，餵給 Google NotebookLM，一鍵生成卡通風格導覽與投影片大綱。

在構建「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) ); 這個改變帶來的紅利是巨大的： ...

哈爸實驗室：技術與應用生態全景圖 這張圖展示了「哈爸筆記」作為核心技術引擎，如何支撐並孵化出「2026 台灣河流探索」這個實踐場域。 graph TD %% === 定義可視化樣式 (Styles) === %% 核心技術區 (Core) - 藍/綠色系 classDef C_Mind fill:#e1f5fe,stroke:#01579b,stroke-width:2px; classDef C_Infra fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px; classDef C_AI fill:#fff3e0,stroke:#ef6c00,stroke-width:2px; classDef C_Comm fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px; %% 應用場景區 (River) - 大地色/深色系 classDef R_Vision fill:#4285F4,stroke:#0d47a1,stroke-width:2px,color:white; classDef R_Content fill:#F9A825,stroke:#f57f17,stroke-width:2px,color:black; classDef R_Tech fill:#2E7D32,stroke:#1b5e20,stroke-width:2px,color:white; classDef R_Meta fill:#607D8B,stroke:#263238,stroke-width:2px,color:white; %% === Core Domain: 哈爸筆記技術堆疊 === subgraph CoreDomain [🛠️ Core Tech: 哈爸筆記技術堆疊] direction TB subgraph C_Phase1 [GenAI 思維模組] Expert(複製專家思維):::C_Mind V2B(Voice-to-Blog 自動化):::C_Mind Insight(GAI 年會洞察):::C_Mind Insight --> Expert --> V2B end subgraph C_Phase2 [雲端基礎建設] GCP(GCP 成本優化):::C_Infra Zeabur(Zeabur 部署 n8n):::C_Infra CloudAI(AI 雲端管理):::C_Infra CloudAI --> GCP --> Zeabur end subgraph C_Phase3 [Agentic AI 實作] BotDebug(Discord Bot):::C_AI Agent(打造 Agentic AI):::C_AI Tool_SQL(SQL 資料庫工具):::C_AI Zeabur --> |提供算力| BotDebug --> Agent --> Tool_SQL end subgraph C_Phase4 [社群擴散] HabaLab(哈爸實驗室 Discord):::C_Comm Event(機械系 50 週年):::C_Comm Agent --> |賦能| HabaLab HabaLab --> Event end end %% === Application Domain: 河流探索計畫 === subgraph AppDomain [🌊 Field App: 2026 台灣河流探索] direction TB subgraph R_Phase1 [願景與方法] Method1(數位河流學):::R_Vision Infra(個人文章網站):::R_Meta end subgraph R_Phase3 [實地探索] Trip1(大甲溪車宿攻略):::R_Content Trip2(后里/高美指南):::R_Content Trip1 --> Trip2 end subgraph R_Phase4 [GIS與數據深化] Data1(Shapefile 轉 KML):::R_Tech Data2(River Buffer 萃取):::R_Tech Schema(SQL Schema 設計):::R_Tech Data1 --> Data2 --> Schema end subgraph R_Phase5 [工具賦能] Tool_Fab(Fabric + Gemini CLI):::R_Tech end end %% === 跨域整合連接 (The Merger) === %% 1. 基礎設施共用 V2B ==> |內容發布| Infra Infra ==> |載體| Trip1 %% 2. 技術賦能 (Agentic AI -> GIS Tech) Agent -.-> |技術指導| Tool_Fab Tool_Fab -.-> |自動化處理| Data1 %% 3. 社群匯流 HabaLab ==> |探索基地| Method1 Method1 --> |指導| Trip1 %% 4. 資料庫整合 Tool_SQL -.-> |Schema 參考| Schema

散步地圖資料庫 Schema 設計 (AI 友善版) 導言 本文件旨在闡述為「大甲溪散步地圖」專案設計的 SQLite 資料庫 Schema。此設計特別考量了 GenAI 協作 (Agentic Workflow) 的需求，選擇使用標準的 WKT (Well-Known Text) 格式來處理地理空間資料，取代依賴性較高的 SpatiaLite 二進位格式。這確保了從資料蒐集、AI 處理到 QGIS 呈現的過程中，資料具有最高的可讀性與移植性。 整體設計哲學 核心資料結構化：確保地理特徵的基本資訊（名稱、描述、類型）保持一致性，便於查詢與管理。 非核心資料彈性化：利用 JSON 格式的 meta_data 欄位，提供高度彈性來儲存多樣化且不斷演進的非核心屬性。 AI 幾何可讀性 (WKT)：全面採用 WKT 字串儲存幾何資料，讓 AI 代理能直接理解、生成與驗證座標，無需複雜的 GIS 驅動程式。 圖層正規化管理：獨立的 layers 表格用於管理圖層的分類和 QGIS 呈現樣式。 AI 協作友好：結構化且彈性的 Schema 設計，極大地方便 AI 代理進行資料的自動化處理、分析與驗證。 社區 GIS 背景資訊與 Layer 分類設計架構 社區 GIS 背景資訊 「社區 GIS」強調地理資訊系統在社區層級的應用，旨在支援地方居民參與、資源管理、文化保存、社會服務及永續發展。這類專案的核心在於將多樣化的在地資訊（例如：親水點、交通、設施、風險、文化景點、生態熱點等）以地理空間的形式進行收集、組織、分析與視覺化。其資料分類通常會考量到以下幾個面向： 功能應用：資料服務於哪種社區需求（如防災、生態教育、文化導覽）。 資料類型：具體的地理實體是什麼（點、線、面，以及相關屬性）。 使用者視角：如何讓在地居民和外部使用者最直觀地理解地圖內容。 Layer 分類設計架構 為呼應社區 GIS 的精神，並支援 QGIS 等工具的靈活呈現，我們特別設計了 layers 表格來管理圖層的分類。其核心架構為 layer_type (主分類) 與 layer_subtype (次分類) 的組合，這種層次化設計有以下優點： ...