Taiwan History Atlas

在完成平面位置 (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城門）全部剁掉，只保留核心字根。 ...