GIS

最近兩天，我跟我的 AI 夥伴 (Antigravity) 泡在 Travel-Advisor-HUD 這個專案裡。目標很單純：讓我的行車助理不再只是「唸出路名」，而是像個真正懂我的「私人導遊」。 在兩天的密集對話中，我們經歷了幾次關鍵的「卡關」與「破繭而出」，這幾個點我覺得是開發地理感知型 AI (Geographic AI) 最迷人的地方。 🚀 什麼是 Travel Advisor HUD？ 這是一個跨裝置的行車助理系統：由 Mac 負責背景運算與大腦邏輯，iPad 則作為沈浸式視覺看板 (HUD)。它能感知你的位置、速度與航向，並結合你過去在 WalkGIS 筆記中的內容，由 Gemini 生成具備人文厚度的即時導覽。 🧩 關鍵卡關與突破 1. 沉重的 Geopandas 與「資料主權」的執念 一開始，我們想用 Python 的 Geopandas 來處理鄉鎮邊界 (SHP) 的空間對位。但在路測邏輯中，Geopandas 顯得過於笨重，且我有一個堅持：「資料主權」。 我不想為了讓 AI 讀數據，就把我珍貴的 walkgis.db (私有筆記) 或內政部的圖資檔案搬來搬去、轉檔轉去。 突破點：我們轉向了 SpatiaLite (SQLite 的空間外掛)。 心得：透過 ATTACH DATABASE 直接掛載原始 DB，並用 VirtualShape 虛擬映射 SHP 檔案。資料「原地不動」，但查詢卻是極速的 SQL 指令。這讓「資料主權」與「運算效能」在這一層完美的對位了。 2. 從「歡迎」到「盤點」的內容層次 原先的導覽很死板：進入新縣市就唸一段 Wiki 簡介。但開車的人真正需要的是：「這裡有沒有我以前記過的東西？」 卡關：AI 雖然強筆強大，但如果你不給它具體的「本地上下文」，它只會說些漂亮但空泛的廢話。 突破點：「行政區點位盤點 (Township Inventory)」機制。 心得：在跨越邊界的瞬間，系統自動在背景先發動一次空間點名，把該鄉鎮內所有關於我的私有筆記 POI 抓出來，做成摘要餵給 Gemini。當 AI 說出：「歡迎來到橫山，這裡有您之前筆記過的內灣車站喔…」時，那種「它真的懂我」的導覽感才算真正建立。 3. Hammerspoon 的定時器與動態設定 Hammerspoon 雖然穩定，但預設的定時器是靜態的。如果我在開車中想調整檢查頻率（比如從 5 分鐘改成 1 分鐘），以往我得停下車，打開 Mac、改代碼、Reload Config。 ...

經過前三篇的努力，我們左手握有中研院的「1920年代空間圖資」，右手拿著從《臺灣通史》榨取出來的「600+ 個古地名與基建列表」。 這就像是一場歷史級別的相親大會——我們要讓書本裡的名字，在歷史地圖上找到歸宿，並將它們賦予現代的 WGS84 GPS 經緯度座標。這個過程，技術上叫做 Geo-Coding (地理編碼)。 同名異地的災難 原以為只要用程式名稱對齊 (Fuzzy Label Matching) 就好，但代誌不是憨人想的那麼簡單！ 台灣地名有驚人的重複率。古書裡寫了個「新莊」或「福興」，如果你不用大腦，程式很容易把北部的事蹟，釘到南部的地圖上，導致座標嚴重飄移。 第一波升級：內政部兵器庫支援 首先，1920 年代的「街庄/大字」顆粒度有時仍不夠細緻，很多《臺灣通史》提到的小聚落找不到。 我決定導入國家級的兵器庫支援：內政部 3 萬筆古地名資料庫 (moi_settlements)。我把這 37,758 筆資料匯入我的資料庫，形成了一個包含了「1920 歷史界線 + 現代文史調查點位」的「三層立體查詢網」。 第二波突破：上下文錨定法 (Hierarchical Anchor) 為了解決同名造成的標記錯誤，我幫自動配對腳本裝上了**「閱讀理解能力」**。 我實作了 guess_anchor 演算法。配對前，程式會先反查《臺灣通史》原文，看看這個地名的上下文寫了什麼。 如果上下文提到了「淡水 / 艋舺」，程式會自動將這個地名的搜尋範圍 錨定 (Anchor) 在「臺北州」。 如果上下文提到「打狗 / 阿猴」，程式就只准在地圖的「高雄州」範圍內尋找這個聚落。 這招「因文定地」，徹底解決了同名異地的痛點！ 史圖合一的瞬間 當我按下 geo_coding.py 的執行鍵，看著終端機不斷吐出 Log： ⚓ Anchored: 中港 -> 對應到苗栗竹南的中港 (24.6853, 120.8519) ⚓ Anchored: 六張犁 -> 成功定錨... ⚓ Anchored: 牛罵 -> 臺中市清水區牛罵頭... 憑藉著上下文疊圖與三層過濾網，我成功地讓近 200 個寫在文言文裡的歷史地名，從泛黃的紙張上躍起，精準降落在 Google My Maps 的紅色圖釘上。 ...

上一篇提到，為了驗證地形圖上的「黃金洞」與歷史水利的關聯，我決定打造一個「歷史空間感知引擎」。要建構這套系統，第一步就是要獲得一把能夠解開空間座標的鑰匙。 我將目光轉向了中央研究院的 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:鄉鎮導航 在 WalkGIS 的開發過程中，我們面臨一個巨大的挑戰：台灣有 22 個縣市、368 個鄉鎮市區，總共 390 個行政單元。如果只是把邊界畫出來，那只是地圖；但如果要讓每個區塊都具備歷史、文化與生活感，那就是一項浩大的工程。 今天，我們完成了「鄉鎮導航」地圖的基礎設施建置。這不只是一張標記邊界的地圖，更是我們發展出的一套「行政區劃富化方法論」。 ...

從「靜態手冊」到「動態地圖」：山海圳國家綠道的數位敘事化轉型實錄 🌏 前言：數據的「生命力」 山海圳國家綠道（MTSW）是一條長達 177 公里的「溯源風土之河」。然而，長期以來這些珍貴的資訊分散在厚重的 PDF 手冊（112MB）與僅具備基本座標的 KMZ 檔案中。對於徒步者而言，在路途上翻閱 PDF 極其不便，而純粹的導航點又缺乏文史脈絡。 本文紀錄了利用 AI 協作，將山海圳從「靜態資料」轉型為「動態地圖系統」的完整工序。 WalkGIS:山海圳國家綠道 NotebookLM投影片 🛠 五大轉化階段 1. 骨架提取：從 KMZ 到空間索引 首先，我們解構了原始的 山海圳營運地圖.kmz。 斷開連結：在匯出時選擇不勾選「網路連結同步」，確保取得的是包含 109 個 POI 與 31 段軌跡（Tracks）的靜態座標資料。 空間格式化：將座標轉化為 WKT (Well-Known Text) 格式（如 POINT(...), LINESTRING(...)），這讓 AI 能在後續處理中理解地理位置。 2. 敘事賦能：批次化的「深度研究」 這是最具挑戰性的階段。109 個點位若逐一改寫，耗時緩慢。我們採取了「批次豐富化 (Batched Enrichment)」策略： AI 協調者模式：將 POI 分為「台江內海」、「大圳之路」、「原鄉之路」與「聖山之路」四個文化生活圈進行改寫。 內容增量：不只是複製手冊，而是透過 AI 挖掘歷史背景、加入在地美食推薦與實用的旅人筆記。這將原本冷冰冰的點位，轉化為具有「生活溫度」的內容。 3. 結構化轉置：Markdown 作為中繼 每個 POI 點位都被轉化為一個獨立的 Markdown 檔案。 YAML Frontmatter：包含類別、日期、座標與 WKT 等 metadata。 標準化資訊卡：在文末提供統一的 📬 資訊卡 區塊，方便系統讀取地址與聯絡電話。 4. 系統整合：WalkGIS 資料庫同步 透過 Python 腳本將上述 Markdown 資料與地圖邏輯匯入 WalkGIS (SQLite) 資料庫。 ...

在將既有的 GIS 開放資料（如 QGIS 專案中的 Shapefile）整合進 WalkGIS 系統時，最常遇到的挑戰往往不是座標轉換，而是文字編碼（Encoding）。 最近在處理「濁水溪流域情報地圖」中的「百年舊堤」圖層時，我遇到了一個經典的亂碼案例。這篇文章將紀錄問題的成因、誤判的過程，以及最終的正確解法，作為未來處理 GIS 舊資料的參考。 案例背景 我試圖將一份名為 23座百年舊堤.shp 的檔案匯入我的 WalkGIS SQLite 資料庫。 1. 初次嘗試：預設轉檔的失敗 一開始，我直接將 SHP 轉為 KML/KMZ 進行預覽。結果在 KML 中，所有的堤防名稱都變成了無法辨識的亂碼，如： 偌 這些字並不是常見的「」或亂數，而是顯示為 PUA (Private Use Area) 區域的罕見字元。這是一個強烈的訊號，代表編碼解讀錯誤。 2. 直覺誤判：這一定是 Big5 台灣早期的 GIS 資料（尤其是政府開放資料），絕大多數的 .dbf 屬性表都使用 Big5 (CP950) 編碼。當看見中文變亂碼時，直覺反應通常是：「啊，這一定是工具用 UTF-8 去讀 Big5 造成的。」 於是我在 Python 腳本中強制指定了編碼： # 錯誤的嘗試 gdal.SetConfigOption("SHAPE_ENCODING", "CP950") 結果出乎意料：亂碼依然存在，甚至變成了另一種形式的亂碼。如果您嘗試用各種 Big5/Latin1 交叉解碼都無效，那問題可能比想像中複雜。 真相：雙重編碼災難 為了找出真相，我使用 ogrinfo 指令進行了雙盲測試（A/B Testing）： 測試 A：指定 CP950 ogrinfo -al -so --config SHAPE_ENCODING CP950 "23座百年舊堤.shp" > Name (String) = 偌 (亂碼) 測試 B：不指定 (預設/UTF-8) ...

在處理台灣水利地理資訊時，常會發現政府公開的「中央管河川」圖資（如 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 建置工作。 ...