AI

在實現 QGIS 專案「一鍵生成」的路上，我們不僅要讓圖層「開得出來」，更要讓它「具備研究價值」。 這篇文章記錄了我們從 POC2 (樣式與標籤整合) 進化到 POC3 (空間分析與 SDM 紀律) 的完整心路歷程。這兩個階段分別解決了製圖中的「美學溝通」與「科學建模」兩大核心問題。 🎨 POC2：視覺精煉與動態標籤 (Visualization & Labeling) 目的：讓地圖「會說話」，透過自動化配置解決手動製圖中最繁瑣的排版工作。 在 POC1 成功掛載圖層後，我們發現原始的點位與線條在混亂的歷史底圖（如台灣堡圖）上極難辨識。POC2 的核心目標即是透過腳本，賦予地圖專業的視覺外觀。 1. 幾何感知的自動標註 (Geometry-aware placement) 我們實現了腳本對圖層類型的自動識別與對應配置： 點位圖層 (遺址)：自動採用 Centroid 配置，讓標籤精確落在遺址中心。 線段圖層 (河流)：自動切換為 Around Line (平行排列)，並預設帶有 0.5mm 的偏移量。這讓河名能順著水流蜿蜒，展現專業製圖感。 2. 跨平台字型與視覺消隱 (The macOS Fix) 我們在 POC2 中遭遇了字型相容性的重擊。原本預設的字型在 Mac 上會毀掉專案解析。最終，我們強制切換為 PingFang TC (萍方-繁)，並自動啟用了 0.7mm 白色光暈 (Text Buffer)。這小小的光暈，是讓地圖文字從花綠底圖中「浮現」出來的關鍵。 🛡️ POC3：空間分析中樞與 SDM 紀律 (Advanced Analysis & SDM) 目的：從「資料顯示」進化為「規律開發」，在不污染原始數據的前提下，自動生成分析模型。 當地圖變漂亮後，下一步就是「看見模式」。POC3 挑戰的是自動產出具有研究深度的分析圖層（如海拔區間與熱點圖）。 1. 恪守 SDM 紀律：絕對不改動原始資料 (Data Hub Snapshot) 開發者常為了分析方便，在原始 SQLite 裡建 View。但對歷史數據來說，原始碼應該是神聖的 (Holy Source)。 我們實作了「局部資料中樞 (Local Data Hub)」：腳本在產出專案的一瞬間，自動建立一個 poc_data_hub.db 快照。所有的 JSON 萃取、高程分區計算都只存在於這份快照中。原始 HGIS 資料庫保持 100% 乾淨，專案檔則是「可打包、可重製、可拋棄」的。 ...

在進行 HGIS（歷史地理資訊系統）研究時，我發現最耗時的往往不是分析數據，而是「準備地圖」。每次要開啟一個新研究，總要重複掛載百年歷史底圖、設定 KML 座標、調整 SQLite 的 SQL 篩選器…。 為了打破這個瓶頸，我發起了一場實驗：能不能像寫程式一樣，用「寫」的出一份 QGIS 專案？ 這就是我最近在推動的 軟體定義地圖 (Software-Defined Maps, SDM) 概念。 🏗️ 為什麼要自動化？ 如果你手動配置過 QGIS，你一定遇過這些崩潰瞬間： URL 特殊字元破壞專案：WMTS 的 URL 裡一堆 &，手動貼上 XML 常報錯。 座標系統 (CRS) 位移：明明設定了 WGS84，圖層卻飄到非洲西岸海面（座標 0,0）。 重複定義的勞力：每個專案都要重新分組（底圖、水理、點位），這應該交給機器人。 透過 Python + Jinja2 模板，我們可以把地圖專案變成可程式化的零件。 🛠️ 基本作法：Jinja2 零件化 核心思路是將 .qgs 專案檔（實質是 XML）拆解為模板。 我們建立了一個 base_project.qgs.j2，裡面預留了動態注入的內容： 層級化圖層樹：自動生成的分組。 資料源設定：SQL 篩選指令與檔案路徑。 空間參考系統：自動注入對應的 AuthID、Proj4 與 SRID。 最關鍵的「零件庫」是 GIS_KNOWLEDGE.yaml。它充當了 GIS 資源的「DNS 伺服器」，記錄了所有中研院底圖、本機 KML 與資料庫的 Metadata。 🚀 第一階段 POC：曾文溪 HGIS 數位中樞 在這次的 POC 中，我們成功實現了 Zengwen_HGIS_Hub.qgs 的一鍵產出： ...

在完成平面位置 (X, Y) 的座標標註與河流距離分析後，我總覺得地圖還少了點什麼。直到我們引入了 Z 軸——也就是高程數據，整個曾文溪流域的歷史才真正「活」了起來。 這是我在 HGIS 建模中最精彩的一場實驗：運用 20m DTM (數位地形模型)，讓遺址開口說出三千年來海陸變遷的秘密。 🏔️ 海拔高度：決定「是海還是陸」的生死線 在台南平原，海拔 5 到 10 公尺是一個神奇的區間。 透過 scripts/enrich_sites_with_elevation.py，我們讓 133 處曾文溪流域遺址自動去匹配內政部的 DTM 資料。這是一個跨縣市的圖磚掃描工具，能精確取出每一筆數據的高度。 考古證詞：南科考古館的案例 以 南科考古館 為例，其海拔約 5-7 公尺。 三千年前：這裡的海拔正好處於古台江內海的沙丘邊緣。大坌坑遺址中發現的「貝塚」，證明了這裡曾是海景第一排。 一千年前：隨著曾文溪泥沙沖積，海拔 6 公尺處變成了濕地與三角洲。 今日：它縮到了離海岸 30 公里的平原中心。 海拔等高線，正是這場「海退人進」演義中的指揮線。 🤖 Layer 3：讓 AI 具備「大歷史語義」 當我們有了 XY 座標、河流距離與 Z 軸高度後，我問了 AI 助理一個問題：「能根據這些數據，幫我寫出一段吸引人的導覽文字嗎？」 這就是 Layer 3：大歷史語義層 (Semantic Context Layer)。 我開發了 scripts/batch_l3_enrichment.py 作業管線。它不只是跑跑程式，而是讓 Gemini 扮演一位考古學家，結合這三個維度的數據，自動生成「地理歷史脈絡」。 AI 生成範例： 「這處遺址位於海拔 540 公尺的穩定河階，離曾文溪主流恰好保持 2.2 公里的安全觀測距離。這顯示先民在金屬器時代已具備極強的避災智慧，選擇了這塊永遠免疫洪水改道的『定海神針』…」 🛠️ 釋出指南 (Release Guide) 這一系列針對考古與地貌的深度模型，我已全數彙整進 Taiwan History Atlas 儲存庫的 v260306.1 更新 中。 ...

當我們在地圖上標註了全台兩千五百多個考古遺址後，下一個問題是：「為什麼他們要住在這？」 在傳統的 HGIS 中，我們習慣去找「古地圖」。但面對三千年前的遺址，世界地圖還是一片空白。這時，我們必須切換思維，引入 Layer 4：空間拓樸分析 (Spatial Topology)。 📐 什麼是 Layer 4？跳脫物理地表的「相對關係」 如果說 L1 是點位，L2 是知識，那麼 Layer 4 就是「點與環境的交互作用」。 我不想只是知道遺址在哪裡，我想知道它與「生存資源」——特別是河流的幾何關係。在曾文溪流域，河道會擺盪、海岸線會進退，但人類對於「取水與避災」的空間邏輯往往是恆定的。 透過 scripts/poc_l4_tributary_clustering.py 這個對合引擎，我們讓 2,249 個遺址自動去尋找它們對應的主流與支流，計算出精確的「離水距離」。 📊 數據發現：離水 2.5 公里的生存密碼 透過分析，我們在曾文溪流域發現了一個驚人的統計規律： 濱海初始期：離水最近距離平均約 2,700 公尺。 長期定居點：離水最近距離平均約 2,200 公尺。 這是一個 「生存甜蜜點」。 在那個沒有堤防的年代，住得太近（如 1km 內）會面臨曾文溪猛烈氾濫的改道威脅；住得太遠又取水不便。 這 2.5 公里的緩衝帶，正是史前先民在沒有現代水利工程的情況下，利用地形與距離「換取安全」的生存智慧。 🛠️ 核心工具：空間特徵標記 (Feature Extractor) 為了實現這種規模的運算，我在儲存庫中提供了一個關鍵腳本： scripts/feature_extractor.py：它不只記錄座標，更會透過幾何運算為每個點位打上「空間標籤」。例如：是否位於「河流樞紐」、屬於哪個「次流域」、以及其「離水梯度」。 這樣的設計，讓 AI Agent 在解讀資料時，不再只是讀到一串數字，而是讀到一個 「人類與環境博弈的空間邏輯」。 🤖 AI Skill 的深度應用 這項分析成果已整合進我們的 HGIS Architect AI Skill。 目前的 AI 助理不再只是會翻翻方志摘要，當你開啟此 Skill 並指向一個座標時，它能調用 L4 的拓樸數據告訴你：「這個位置雖然現在離曾文溪很遠，但在三千年前，它正好位於主要支流的交會口，是一個戰略性的交通節點。」 ...

在之前的 HGIS 系列中，我們主要處理的是「紙上的歷史」——透過方志與古籍還原清代的社會空間。然而，要真正觸摸到「台灣主體性」最深層的脈絡，我們必須將目光投向更長的時間尺度：考古遺址。 如果說《臺灣通史》記載的是數百年的族群演進，那麼埋藏在台南平原地底下的「文化層」，則是長達數千年的地景變遷證詞。 今天，我正式在 Taiwan History Atlas 專案中發布了 v260306.1 更新，核心重點就在於建構一套具備「血緣追蹤」能力的 考古遺址 Master Registry (主註冊表)。 🏛️ 為什麼我們需要 Master Registry？ 在處理全台遺址資料時，最頭痛的不是「沒資料」，而是「資料太多且碎片化」。文資局有「法定遺址」、中研院有「普查遺址」、地方政府還有「疑似遺址」。 要在 AI 輔助下進行科學分析，我們不能只是貼貼補補，必須建立一個 Master Registry： 資料對齊：解決同一個遺址在不同單位有不同名字 or 座標微差的問題。 層級化建模：將原始資料 (L0) 轉化為帶有語義標籤的實體 (L1)，再整合進知識中樞 (L2)。 血緣追蹤 (Source Origin)：每一筆數據都能回溯到是哪個單位的原始點位，確保「證據力」。 目前這套系統已成功整合了 2,563 處 遺址，成為我們 HGIS 引擎中最堅實的核心數據庫。 🛠️ 核心腳本與工作流 (Scripts Toolkit) 在 taiwan-history-atlas 儲存庫中，我們透過以下工具實現了這一流程： 1. Layer 1：實體萃取與特徵標記 利用 scripts/extract_entities.py，AI 會自動掃描原始 Open Data 文本，提取出： 文化年代：從大坌坑、蔦松到金屬器時代。 遺址等級：Rank 1（國定）到 Rank 4（疑似）。 特徵標籤：貝塚、石器、多層疊壓等。 2. Layer 2：跨庫遷移與合成 使用 scripts/atlas_migrator.py，將分散在各區域的實體統一遷移至 data/history_atlas.db。這個過程不只是搬家，更是在進行「去重 (De-duplication)」與「血緣標註」。 ...

當我們開始嘗試將 AI 與歷史地理資訊系統 (HGIS) 結合時，最初是在探勘總體性的《臺灣通史》。但歷史的魔鬼往往藏在地方的細節裡。 為了驗證我們的架構是否具備「橫向擴展」到區域史料的能力，我將目光轉向了北台灣早期的政經中心——竹塹 (新竹)。這次，我決定一次挑戰五本重量級的地方方志：《新竹縣採訪冊》、《淡水廳志》、《樹杞林志》、《新竹縣志初稿》、《新竹縣制度考》。 這五本書，總計 34 卷、9,000 多條史料片段。如果單靠純文本搜尋，那就像是在汪洋中撈針。 今天，我正式在 Taiwan History Atlas 專案中，釋出了這套針對新竹史料開發的「多書跨卷整合與空間對合框架」，並同步上線了 竹塹五書歷史知識地圖。 🏗️ L0-L1-L2：史料的階梯式煉金術 要讓 AI 不會在這 9,000 多條文獻中「幻覺」，我們採用了嚴謹的「分散式溯源，集中式建模」三層架構： 1. L0 文獻底座 (Text ETL) 有別於單一文本，地方方志的卷次編排極度不一致。透過 hsinchu_multi_loader.py，我們實作了多種 Regex 解析器，一次性將五本史書的目錄、卷次、條目全部打散又重組，完美塞入 hsinchu_history.db 的標準 Documents -> Volumes -> Contents 結構中。 2. L1 實體萃取與降維對合 (Entities & Linkage) 光有文字不夠，我們需要提取「有意義」的節點。 透過 AI 輔助腳本，我們一口氣從五書中抓出了三類實體： Infrastructure (基礎建設)：1,410 筆（橋樑、隘口、古道、城門等）。 Location (聚落空間)：4,343 筆（堡、里、庄、社、窠、坑等）。 Irrigation (水利開發)：834 筆（陂圳、埤塘、水門等）。 但困難來了：古地名在地圖上是找不到座標的！ 例如史書寫「隆恩圳」或「林先坤陂」，現代 Google Map 根本不知道在哪。 這時我們啟動了 「地理特徵降維打擊」 的演算法。我們寫了清洗函數（如 clean_infra_name, clean_water_name），把地名的尾巴（像是 xxx庄、xxx圳、xxx城門）全部剁掉，只保留核心字根。 ...

最近在整理 WalkGIS 的「濁水溪流域地圖」，資料庫裡累積了近 400 個景點 (POI)。看著這些密密麻麻的點，我突然萌生一個念頭：「能不能請 AI 幫我規劃一趟從海口走到源頭的四日遊？」 這原本只是一個隨性的提問，沒想到 AI 利用資料庫中的經度 (Longitude) 資料，展現了令我驚豔的規劃能力，甚至連車宿點和美食導航都一手包辦。 1. 驚豔的「經度切分法」 過去規劃行程，我們常是對著地圖發呆，一個個把點連起來。但這次，AI 展現了工程師的思維： 「根據資料庫中的 390 個景點，按經度由西（海口）向東（高山）排序…」 它寫了一支簡單的 Python 腳本，直接讀取 walkgis.db，將所有景點依經度排序，然後切分成四個區塊： Day 1: 海口風情與糧倉沃野 (經度 < 120.40) 起點：麥寮港 / 濁水溪出海口 重點：見證大河入海的壯闊與工業/漁村並存的景象。 推薦停靠： 麥寮拱範宮：國定古蹟，海口信仰中心。 鷺鷥生態景觀公園：觀賞濕地生態。 詔安客家文化園區：探訪崙背/二崙的詔安客家文化。 米香囍懷舊農村生活館：體驗稻米文化。 私房點：下溪墘堤防看夕陽。 Day 2: 橋樑、古鎮與分水樞紐 (經度 120.41 - 120.65) 區域：西螺、溪州、二水、林內 重點：濁水溪最精華的人文段，看大橋與分水工。 推薦停靠： 西螺大橋：必訪地標，連結雲彰兩岸。 溪州尚水 / 森林公園：體驗友善農耕與台糖鐵道歷史。 林內一號/二號進水口：看濁水溪如何被引入嘉南大圳。 二水車站：集集線起點，鐵道迷聖地。 私房點：二水堤防國聖碑。 Day 3: 集集支線與淺山聚落 (經度 120.65 - 120.85) 區域：竹山、集集、名間、水里 重點：進入丘陵區，沿著集集支線火車溯源。 推薦停靠： 竹山文化園區 / 菸葉場：認識竹藝與菸草歷史。 集集車站 / 綠色隧道：騎單車漫遊。 明潭/大觀發電廠：水里鄉的水力發電重鎮。 鹿谷鳳凰谷鳥園 / 麒麟潭：往南延伸至鹿谷茶鄉。 私房點：甘泉井及石頭公。 Day 4: 雲端秘境與源頭探索 (經度 > 120.85) 區域：信義、日月潭、仁愛、合歡山 重點：深入中央山脈，尋找濁水溪的源頭。 推薦停靠： 日月潭 (水社/伊達邵)：雖是水庫，但水源來自濁水溪武界。 東埔溫泉：在陳有蘭溪畔泡湯（濁水溪最大支流）。 奧萬大國家森林遊樂區：萬大溪流經的賞楓勝地。 武界部落 (曲冰遺址)：被稱為「雲的故鄉」，濁水溪最美河段之一。 終點：合歡山主峰/東峰 (遠眺濁水溪源頭霧社溪)。 這個行程剛好涵蓋了工業、農業、水利、鐵道、觀光到高山生態，是認識台灣母親之河的絕佳路線。 ...

在處理台灣水利地理資訊時，常會發現政府公開的「中央管河川」圖資（如 RIVERL.shp）或河川代碼表，往往只記錄到一定規模以上的河川。很多在地人熟知的區域排水、野溪或深山源頭（如濁水溪上游的霧社溪）並不在名冊上。 這篇筆記記錄了我在 WalkGIS 專案中，如何運用 AI 助理與網路資源，像拼圖一樣將這些「隱藏版」溪流補回資料庫的過程，並將其標準化為可重複執行的 Task。 1. 發現缺漏 (The Gap) 在整理「濁水溪」圖資時，我對照了目前的 GIS 圖資與網路搜尋結果，發現幾個明顯的斷層： 深山源頭缺失：地圖上有畫出濁水溪，但官方 CSV 名冊卻沒有列出其源頭「霧社溪」。 知名支流不見：如「萬大溪」、「丹大溪」雖然在 CSV 名冊上有名字，但因為不是主要治理河段，在部分公開 SHP 圖資中完全沒有線條。 在地小溪隱形：如「益則坑溪」、「栗棲溪」，是當地的戲水秘境或土石流潛勢溪流，但在中央級的資料中找不到。 這些「缺漏」對於一般用途可能無傷大雅，但對於要進行深度走讀（River Walk）的我們來說，少了它們就像拼圖少了一塊。 2. 補完策略 (The Strategy) 我的目標是建立一份「完整的流域戶口名簿」。即使手上暫時沒有這些溪流的精確 GIS 線條，也要先把它們的名字及**輩分關係（注入哪條河）**記錄下來。 步驟 A：查找「隱藏版」名單 透過網路搜尋（Google Search / Wikipedia / 縣市政府水利規劃報告），找出那些屬於濁水溪流域但未被登錄的河川。例如這次我新發現了： 霧社溪 栗棲溪 獅尾堀溪 益則坑溪…等 步驟 B：確認「輩分關係」 (Topology) 這是最關鍵的一步。在 GIS 資料庫中，我們不只要知道這條溪叫什麼，更要知道它從哪裡來、往哪裡去。也就是確認它是直接注入濁水溪（第一層），還是先注入其他支流（第二層）。 我使用了以下工具來進行「親緣鑑定」： OpenStreetMap (OSM)：使用 Overpass Turbo 查詢，如果運氣好（如霧社溪），Relation 中會直接標註 destination=濁水溪。 地方政府報告：例如從「南投縣管區域排水規劃」中，確認了「獅尾堀溪」是濁水溪左岸的支流。 地理推斷：如「益則坑溪」位於水里鄉民和村，該村緊鄰濁水溪，推測直接注入主流可能性大。 步驟 C：修訂 CSV 結構 為了將新發現納入系統，我在 河川代碼主從.csv 中手動增補資料。為了不與官方 6 碼數字衝突，我設計了一套「非官方編碼規則」： ...

最近在研究 LASS 社群維護的 「流域情報開放地圖」 QGIS 專案，這是一個集結了政府開放資料與民間調適計畫成果的龐大資料庫。 資料雖豐富，但若只想專注於特定流域（例如：濁水溪），要從全台的圖資中「萃取」並「整理」出有結構的資料，手動操作相當繁瑣。這次我嘗試透過 AI 助理 Antigravity 來協助處理，發現這是一個非常高效的工作流，特別是針對舊式 Shapefile 資料結構的梳理。 以下分享這次的實作筆記，以及一個關鍵的發現：河川代碼 CSV 的重要性。 1. 任務目標 從全台的 GIS 圖資中，提取出 濁水溪流域 的完整資料，並轉換成 Google Earth 可用的 KMZ 格式。需求包含： 流域範圍：濁水溪集水區的面資料 (Polygon)。 河道水系：包含主流與所有支流的線資料 (Line)。 層級結構：需區分主流、一級支流（如陳有蘭溪）、二級支流（如和社溪），並以不同顏色與資料夾呈現。 2. 關鍵資料解析 在專案目錄中，主要的幾何資料位於 1-流域水文地理環境 下的 RIVERL.shp（全台中央管河川）。原本以為只要用 SQL 篩選 BASIN_NAME = '濁水溪' 即可，但 AI 分析後發現了一個隱藏的寶藏檔案： 📂 檔案位置： 河川整理資料 - 河川代碼主從 這份 CSV 檔案是解析河川「拓撲關係（Topology）」的關鍵，沒有它，GIS 圖資就只是一堆沒有從屬關係的線條。所以也很容易做出下圖 為什麼這份 CSV 很重要？ Shapefile 本身雖然有 RV_NO (河川代碼)，但要從代碼反推「誰是誰的上游」需要複雜的解碼邏輯。而這份 CSV 直接建立了樹狀結構： 欄位 說明 範例 (陳有蘭溪) river_id 河川唯一碼 151010 river_name 中文名稱 陳有蘭溪 in_id 注入的河川 ID (Parent) 151000 (注入濁水溪) river_link 全路徑字串 0@151000@151010 AI 應用的邏輯技巧 透過 Antigravity，我們利用 river_link 欄位快速算出了河川的「層級 (Stream Order)」，邏輯出奇簡單： ...

引言：打造「百科全書式」的流域地圖 一直以來，我對於製作「有深度」的地圖充滿熱情。一張好的地圖，不應該只是標記與導航，它應該能承載歷史的厚度、文化的溫度，以及地理空間的邏輯。 這次，我以台灣的母親河——濁水溪為範圍，嘗試進行了一次「百科全書式」的探索與實作。我的目標是將這條河流從合歡山源頭到麥寮出海口，涵蓋自然地景、水利設施、人文史蹟、交通設施、災害環境五大維度的知識，轉化為可互動、可導航的數位資產。 這篇文章記錄了我如何利用 AI Agent 與自動化腳本，將大量且發散的研究資料，快速收斂為 WalkGIS 系統中的標準化地圖。 實作流程解析 我的工作流主要分為三個階段：Deep Research (發散) -> 結構化萃取 (收斂) -> 自動化生成 (Agent Task)。 階段一：Deep Research 與維度定義 首先，我並不是直接開始畫地圖，而是先進行研究。我定義了濁水溪流域的五個觀察維度： 自然 (Nature): 包含源頭的合歡山、地質敏感的金門峒斷崖、以及河口的濕地生態。 水利 (Water Infrastructure): 這是濁水溪的靈魂。從上游的霧社水庫、武界壩，中游的集集攔河堰，到下游滋養彰雲平原的八堡圳與濁幹線。 人文 (Culture/History): 包含原住民部落（曲冰、武界）、客家文化（詔安）、以及漢人聚落（西螺、北斗）。 交通 (Transport): 見證歷史的西螺大橋、集集車站，以及現代的國道橋樑。 災害 (Disaster/Env): 誠實面對環境課題，如車籠埔斷層保存園區、地層下陷區。 我利用 AI 工具（如 Gemini）針對這些維度進行深度搜尋，挖掘出最具代表性的關鍵字與地點。 階段二：萃取清單 (The List) 研究之後，我將這些發散的資訊收斂為一份結構化的景點清單 (List of Locations)。這份清單不需要包含座標或詳細敘述，只需要準確的「名稱」與「分類」。 例如： 水利：八堡一圳、林內分水工 交通：西螺大橋、溪州大橋 人文：林先生廟、麥寮拱範宮 這份清單，就是餵給 AI Agent 的「種子」。 階段三：Run Task - 自動化生成的魔法 這一步是效率爆發的關鍵。我定義了一個名為 create-walkgis-map-from-list 的 Agent Task，讓 AI 代理人幫我完成那些繁瑣的 GIS 建置工作。 ...