哈爸筆記

上一篇提到，為了驗證地形圖上的「黃金洞」與歷史水利的關聯，我決定打造一個「歷史空間感知引擎」。要建構這套系統，第一步就是要獲得一把能夠解開空間座標的鑰匙。 我將目光轉向了中央研究院的 GIS 寶庫。 寶藏開箱：1920 年代的台灣地理切片 幸運的是，台灣學界已經將日治時期（1920 年代）的行政區劃轉換為數值圖資。我順利取得了當時的「街庄（1920b_1.shp）」與更細緻的村落級別「大字（1920a_1.shp）」Shapefile 檔案。 這兩份檔案就像是兩張巨大的網子，完整罩住了百年前的台灣島。 不過，要將百年前的網子跟現代的手機 GPS 疊合，遭遇了第一個技術難關：座標系的跨時空翻譯。歷史圖資通常使用 TWD67（台灣二度分帶），而我們現在的手機或 Google Maps 則是使用 WGS84 經緯度系統。利用 Python 的 Geopandas 套件，我寫了一段優美的投影轉換代碼，成功讓百年前的地圖「滑」進了現代的經緯網格中。 魔法實做 1：GPS 腳下檢索 (Point in Polygon) 有了吻合的圖資後，我開發了第一個功能。這是一個純粹的數學運算，俗稱 Point in Polygon (點在多邊形內)。 現在，只要我輸入一組現代的 GPS 座標（或許是我走在竹北街頭，或是站在台南的田野），程式就會瞬間吃進這組座標，穿越時空，告訴我：「你腳下站的地方，在 1920 年屬於新竹州新竹郡新竹街！」 魔法實做 2：方圓百里的時光雷達 (Spatial Proximity) 光知道腳下叫什麼名字還不夠，我想要有「導遊」的感覺。 於是我加入了 Buffer（緩衝區）的概念，實作了「附近古地名查詢」功能。想像你站在定點，按下啟動鍵，程式會以你為中心，發射出半徑數公里的虛擬雷達波。雷達波不僅會掃過 1920 年代的各級行政區，更進一步結合了內政部釋出的 3 萬多筆「古地名/歷史聚落」空間圖資。這樣一疊加，所有被涵蓋在範圍內的聚落名稱（甚至是已經消失的微小地名）全部都會列印出來。 這套被我戲稱為「時光羅盤」的模組，讓我們具備了強大的 空間反查能力。 執行例子： python scripts/query_hgis_point.py 24.785150 120.967825 在 1920 年屬於： 🏛️ 州廳: 新竹州 🏰 郡市: 新竹郡 🏘️ 街庄: 香山庄 但問題是，地圖上的地名是冷的。這個古地名背後曾經發生過什麼驚心動魄的故事？有哪個先賢曾經在這裡開圳引水？ ...

一切的起點，源自於對家鄉地名的好奇。 老爸出生在潭後，但我一直不知道為什麼是這個名字。這裡沒有水潭，何來「潭後」之名？如果只是在 Google Maps 上滑動縮放，這個問題可能永遠得不到解答，因為現代的衛星空照圖，早就被密集的建築與柏油路給覆蓋。 於是我開始在網路上搜尋，想知道名稱的可能由來。透過查閱資料，我找到了「北庄13」這條線索，並追溯到了開墾先賢王世傑的紀錄。這才發現，原來在古書中指出，以前頭前溪在此處曾經有一個深潭。 更引人入勝的是，古書原文中還記載著附近有「黃金洞」，但我身為在地人卻從來沒有聽過這個詞！於是，我開始在各種古書中搜尋「黃金洞」，這便是為什麼後來會需要下載並整理好幾本地方志與史書的原因。 例如在《新竹縣採訪冊》記載著水圳「西南行二里至黃金洞，又三里至潭後莊」，另有紀錄點出「西南行一里許至黃金洞，鑿山三十餘丈引水出…經潭後」。這些古籍清晰地描繪了水路行經的節點，但對「黃金洞」本身僅有文字描述，大意就是「在潭後到九甲埔中間有個高起的小山，所以需要挖隧道引水」。既然只有文字描述，於是我心想：那或許可以從 DTM 數值地形去分析它大概的位置？ 我不甘於僅止於文字記載，決定戴上另一副眼鏡——打開具備高解析度的高程資料，俗稱 DTM (Digital Terrain Model) 數值地形圖，試圖在地表尋找先民的遺跡。 DTM 就像是將地表的樹木與建築物全部扒光，只留下最純粹的山地與溝壑起伏。當我將「潭後」附近的地形顯示在 QGIS 上，經由 GIS 處理與高程分析後，確實可以看到一條具備劇烈落差的線。 雖然看到這條線，但傳說中的「黃金洞」確切點位在哪，一開始還是不太知道。於是我將它與目前的現代地圖進行疊加，赫然發現那條異常落差的線上，剛好就有目前的「水源街取水口」！ 直覺告訴我：就是這裡了。而再經過後續的文獻交叉比對，那裡證實就是傳說中「黃金洞」的所在。 這不是外星人的遺跡，而是兩百多年前，我們的先民在缺乏現代大型機具的情況下，為了將水資源從頭前溪引進竹塹平原，硬生生地以人力穿山鑿石，刻下的大型水利基建（引水穿山的隧道）。有了這條隧道，龐大的水流才得以穿過高起的小山，灌溉出兩千甲的良田。 這個 Aha Moment 深深震撼了我。 我體悟到一件事：「地理，其實就是凝固的歷史。」 現代地表上看起來微不足道的一個小土丘、一條乾涸的溝渠、甚至只是一個站牌的名稱「潭後」，在數百年前，可能都是決定整座城市生死存亡的戰略設施。 但下一個問題來了：這條水路是誰修的？什麼時候修的？除了「黃金洞」，台灣的地底下是不是還有無數條這樣凝固在時間裡的生命線？ 為了解開這些謎團，過程中勢必會需要將古書記載與真實的古地圖進行疊加比對。因此，我想先探索一下中央研究院（中研院）到底有哪些相關的歷史圖資資源可以使用。 （未完待續：下一篇，我們將打開中研院的百寶箱，解析歷史圖資的魔法！） 本文為哈爸與 AI 助理協作產出，紀錄實體探勘與數位工程之歷程。

從「空間數據」到「流域敘事」：二仁溪探索計畫中的 WalkGIS 方法論進化 在規劃二仁溪探索計畫的過程中，我不只是在畫一張地圖，而是在進行一場 AI 驅動的「環境策展」。原本我們只關注座標與路徑（ bones 骨架），但在這次二仁溪的實踐中，我們成功注入了「敘事靈魂」（soul）。 以下是本次計畫中，關於 WalkGIS 數位整合與探索流程的三大方法論改良： 1. 「二段式研究法」的誕生 (Deep + Basic Research) 過往我們條列 POI 時，往往直接跳入查詢座標。但在二仁溪這個具備深厚歷史負擔的流域，我們實驗了「先深度敘事、後基礎資料」的二段式流程： Deep Research (敘事研究)：要求 AI 根據著作《南部紋理》的觀點，挖掘流域的「治理歷史」、「地質制約」與「環境救贖感」。這讓 Day 1 到 Day 3 的行程具備了邏輯鏈。 Basic Data Research (基礎研究)：在敘事架構定稿後，再讓 AI 去批次抓取經緯度、補給點與潮汐時間。 效益：這確保了每一條產出的數位資訊（Feature Markdown）都帶有著作中要求的「觀點」，而不僅僅是 Google Maps 上的複製品。 2. 數位資產的「彈性標準化」 在處理大量地圖檔案時，我們遇到「日期未定」與「資產命名」的混亂問題。這次我們修正並正式封裝了以下標準： 2026xxxx 邏輯：在行程日期未敲定前，開發環境統一使用 2026xxxx_ 作為 ID 前綴。這讓檔案在資料庫（walkgis.db）與檔案系統中保持唯一性，未來日期確定後，僅需一次批次取代即可上線。 KML 幾何合併 (Dissolve)：過往匯入 Google My Maps 的河道線段極為細碎。這次我們改寫腳本，依據 RV_NAME 欄位將主流與支流合併為 MultiGeometry。這讓地圖圖格更整潔，且能一鍵選取整條溪流。 3. WalkGIS 資料庫的「敘事耦合」 (DB Sync v2.0) 我們在 walkgis.db 的同步上做了重要突破，讓 Markdown 檔案與資料庫不再是並行線，而是深度耦合： ...

哈爸筆記： 有時候最專業的工具不一定是最快的工具。這是一次從「想學專業軟體」到「讓 AI 寫專屬程式」的心路歷程，也驗證了人機協作中「人類提供結構，AI 提供執行」的高效模式。 1. 背景：細節與強度的拉扯 在田野中發現了一張細節極其豐富的珍貴舊地圖。這類地圖有個特性：如果你想一張照片拍完，細節（尤其是文字）會因為解析度不足而變得模糊不清。 為了保留所有細節，我採取了「局部特寫」法：分別拍下地圖的四個角落。照片是清晰了，但挑戰也來了：如何把這四張帶有手拿變形、光影與透視差異的照片，拼回原樣？ 2. 挫折：專業軟體的高牆 一開始我很有志氣地問了 AI，它推薦我使用全景攝影界的開源神器 Hugin。 雖然 Hugin 功能極強，但它的介面充滿了攝影測量學的專有名詞：焦距 (Focal Length)、失真係數 (Lens Projection)、控制點 (Control Points)…等。即便對著 AI 給的指南操作，我依然在無數次的對齊失敗與複雜的參數設定中感到挫敗。對我來說，我只是想拼一張圖，並不想成為攝影量測專家。 3. 轉機：AI 代理程式的「灰盒」實驗 我決定把「死馬當活馬醫」，直接請我的 AI 代理程式 (Antigravity) 寫程式處理。過程中我也學到了一課： 全自動的失敗 (Black Box)：一開始 AI 給了一支使用 OpenCV 內建 Stitcher 的程式。這類「黑盒」工具在處理旅遊風景照很強，但面對手拿翻拍、重複特徵不明顯的地圖時，演算法直接放棄（回報失敗碼 1）。 關鍵的人類介入 (Human-in-the-loop)：我發現機器缺的是「空間感」。我主動告訴 AI 每張圖檔對應的位置： 左上：IMG_4953 右上：IMG_4955 左下：IMG_4954 右下：IMG_4956 精準執行：有了這份資訊，AI 放棄了不穩定的全自動模式，改寫一支基於 SIFT 特徵匹配與透視變換的客製化腳本。 4. 技術大腦：這支程式的工作邏輯 這支 Python 程式不再是瞎猜，而是執行了以下步驟： 特徵提取 (SIFT)：在照片中尋找數千個數位特徵（如地圖上的線條交會點、古文字的筆畫）。 空間受限匹配：利用我提供的佈局，限定程式只比對「鄰接」的邊界，這大大降低了機器「認錯特徵」的機率。 透視投影變換 (Homography)：這是最重要的一步。手拍照片一定有歪斜，程式透過數學計算，將照片進行如同 3D 空間般的「拉伸對齊」，確保地圖上的道路能無縫銜接。 三階段融合：先拼左半部、再拼右半部，最後合體。 5. 心得：AI 時代的「灰盒」策略 這次經驗讓我體會到，我們不一定要去硬啃專業軟體的說明書。最有效率的方式是 「灰盒策略」： ...

這是我日本行的第二天。今天主要前往奈良看鹿，晚上回到大阪享用美食。 以下是實際去過的地方與買吃的東西： 🦌 奈良公園 (Nara Park) 官方網站 來到奈良當然不能錯過著名的奈良公園。 餵鹿：這是今天的重頭戲，雖然鹿很可愛，但有時候也挺熱情的，手上的鹿仙貝要拿好喔！ 🍚 志津香釜飯 (Shizuka) Google Maps 午餐選擇了著名的志津香釜飯。排隊人潮通常不少，但堅持傳統風味的釜飯，米飯吸滿了高湯精華，非常值得一試。 ⛩️ 冰室神社 (Himuro Shrine) 官方網站 接著參訪了冰室神社，這裡是著名的「製冰業守護神」。除了祈求好運，欣賞神社的靜謐氛圍也是一種享受。 抽了張 第 20 號大吉的籤 🏯 東大寺 (Todaiji Temple) 官方網站 宏偉的東大寺，看到大佛的瞬間真的感到很震撼。 大佛布丁 (Daibutsu Pudding)：Google Maps 參拜完特別買了有名的大佛布丁，瓶蓋上有可愛的大佛圖案，口感綿密濃郁，是很好的伴手禮或甜點。 🥘 福太郎 - 梅田店 (Fukutarou) 官方網站 晚餐回到大阪梅田，選擇了福太郎大阪燒。這裡是品嚐正宗大阪燒（Okonomiyaki）與蔥燒（Negiyaki）的好地方，坐在鐵板板前看著師傅料理，香氣四溢，為第二天畫下完美的句點。 AI 協作宣告 (AI Collaboration Disclosure) 本文內容由 AI 協作生成： 素材來源：哈爸提供行程與筆記。 文章生成：Antigravity 協助整理與撰寫。 文章落地：Antigravity 協助排版與發布。