GIS

在開發 AI Field Scout (AI 偵查員) 系統的過程中，我們的一個核心需求是：讓 AI Agent 能即時把發現的資訊（例如：附近的便利商店、危險地形、或是沿著路徑移動的隊友）投放到使用者的 ATAK 地圖上。 ATAK (Android Team Awareness Kit) 是一個非常強大的戰術地圖軟體，它使用 CoT (Cursor on Target) 這種 XML 格式來交換訊息。網路上大部分的教學都推薦使用 UDP Multicast，但在實際的開發環境（特別是 Mac 電腦連接 iPhone 熱點，或是複雜的內網環境）中，UDP 經常因為路由、防火牆或廣播限制而撞牆。 經過了一番「通訊地獄」的除錯後，我們總結出了一套最穩定的解決方案：使用 TCP 直連。 這篇筆記將分享如何用 Python 建立一個穩定的 CoT 發送器，讓你的程式碼能直接控制 ATAK 地圖上的標記。 為什麼選擇 TCP 而不是 UDP？ 雖然 CoT 的原生設計大量依賴 UDP Multicast 來達到「即插即用」的群組廣播效果，但在點對點（Point-to-Point）的開發測試中，UDP 有幾個痛點： 網路不可靠：在手機熱點或某些 Wi-Fi 設定下，Multicast 封包常被丟棄或過濾。 除錯困難：UDP 是「射後不理 (Fire and Forget)」，程式碼送出去了，你完全不知道對方收到了沒。 路由黑洞：作業系統（特別是 macOS）在多重網路介面下，UDP 出站路由容易走錯路（No route to host）。 相對的，TCP (Transmission Control Protocol) 提供了一個非常明確的機制： ...

在規劃「2026 台灣河流探索」的過程中，除了路線本身的挑戰，最實際的問題往往是：「哪裡可以補給？」以及更重要的——「哪裡有廁所？」。 雖然 Google Maps 很強大，但要一眼在地圖上看出「哪一家超商有廁所」並不容易。於是，我決定自己動手做一張專屬的地圖，並將其整合到我的主力導航工具 Google My Maps 與 ATAK 中。 🚀 任務目標 取得全台灣便利商店的資料。 篩選出標記為「有廁所」的店家。 製作成 Google My Maps 可以吃的 KML 檔。 打包成 ATAK 可以用的 Data Package。 🛠️ Step 1: 資料來源 - OpenStreetMap (OSM) 相較於政府資料只有地址，OpenStreetMap (OSM) 社群維護的資料包含了更多屬性（如廁所、ATM、品牌）。我使用 Overpass API 來抓取資料。 Python 抓取腳本 (核心邏輯) 我們不需要下載整個台灣的圖資，只需針對 shop=convenience 進行查詢： overpass_query = """ [out:json][timeout:60]; area["name:en"="Taiwan"]->.searchArea; ( node["shop"="convenience"](area.searchArea); way["shop"="convenience"](area.searchArea); ); out center; """ 這段腳本會抓下全台約 13,000+ 筆超商資料。 🧹 Step 2: 現實的殘酷 - 資料篩選 抓下來後，我原本期待能有滿滿的廁所清單，結果進行統計後發現： Total Stores: 13,000+ Toilets = Yes: ~550 Toilets = No: ~150 Toilets = Unknown: 12,000+ 顯然 OSM 上關於廁所的標記還很不普及（填寫率不到 5%）。但換個角度想，這 550 間 是經過熱心網友確認「一定有」廁所的精華名單，對於急需的人來說，這就是最可靠的綠洲。 ...

在 上一篇 我們搞定了「有廁所的便利商店」地圖資料。然而，當我們真正走入濁水溪或曾文溪的荒野時，地圖上需要的資訊遠不止這些。 我們需要知道哪裡有攔沙壩 (Weir) 可以觀察水流，哪裡有 吊橋 (Suspension Bridge) 可以跨越峽谷，哪裡有 土地公廟 (Earth God Temple) 可以補給休息。 ATAK 內建的軍規符號太過複雜且抽象，網路上抓的圖示又風格不一。於是，我決定自己動手做一套**「WalkGIS 河川探索專用圖示包」**。 🎯 設計理念：直覺至上 在地圖上（尤其是戶外強光下的手機螢幕），辨識度是第一要務。經過幾次嘗試（從下載 icon 到失敗的 fallback），我發現最有效的方法竟然最簡單： 「直接把字寫在圓圈裡。」 看圖示猜半天這是廟還是房子？不如直接寫個**「廟」**。 這是水壩還是水管？直接寫個**「壩」**。 我將需求分為四大類色系，建立了一套視覺語言： 💚 生存 (Survival) - 綠色：廁、店 (雜貨)、水 (水源)、車 (車宿點) 💙 水利 (Hydro) - 藍色：壩、橋、閘 (水門)、生 (生態點)、景 (觀景) 🧡 人文 (Culture) - 橙/棕：廟 (土地公)、跡 (遺跡)、訊 (解說牌)、村 (部落) ❤️ 危險 (Danger) - 紅色：危 🛠️ 技術實作：Python Pillow 自動繪圖 我寫了一個 Python 腳本 (generate_chinese_icons.py)，完全不依賴外部圖片素材，直接用程式碼「畫」出這些圖示。 核心邏輯 定義設定檔：用一個 List 管理所有圖示的名稱、顯示文字與顏色。 字體偵測：自動抓取 macOS 系統內的 PingFang.ttc 或 STHeiti 中文字體。 畫布生成： 建立 64x64 的透明底圖。 畫一個實心圓圈（帶白邊），顏色由設定檔決定。 將中文字置中寫在圓圈上。 ATAK 打包：生成 iconset.xml 並將所有 PNG 壓成 ZIP 檔。 程式碼與成果 # 部分程式碼片段 def create_text_icon(item): # ... 畫圓與寫字 ... draw.ellipse([4, 4, 60, 60], fill=item['color'], outline='white', width=3) draw.text((x, y), item['label'], font=font, fill='white') # ... 存檔 ... 執行後，我得到了一個 River_Exploration_Icons_Text.zip。 ...

在 WalkGIS 2.0 的開發過程中，我發現早期的地圖資料存在嚴重的 GPS 誤差。本文記錄了如何利用 Google Maps API 進行批次自動化校正，並解決了「台灣中心點」歸零問題、路徑檔被誤改以及資料一致性維護的技術挑戰。

整理 WalkGIS 專案從 2025/12/13 發想至今的完整演進歷程。透過 Mermaid 圖表與詳細里程碑表格，記錄了這個專案如何從單純的「散步地圖概念」，經由 Agentic AI 的輔助，一路進化為去中心化協議 (V2)，並最終整合至軍規 ATAK 系統的技術路徑。

當手上只有一張靜態的工程示意圖，卻想在地圖上畫出真實的管線路徑時，該怎麼辦？本文記錄了我如何引導 AI Agent，透過「座標錨定」與「關鍵點推估」，將圖片中的線條轉化為標準的 WKT (Well-Known Text) 格式，成功在 WalkGIS 上重現大安大甲溪聯通管的地下網絡。

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

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

社區 GIS 圖層分類範例與資料類型 在進行社區地圖繪製或 GIS 資料庫建置時，一個完善的圖層分類架構能幫助我們更有系統地收集與管理資料。以下是整理出的通用型 layer_type (主分類) 和 layer_subtype (次分類) 建議列表，您可以參考這些架構來填充 layers 表格，作為散步地圖的分類依據。 主分類 (layer_type) 建議 我們將社區 GIS 的資料維度劃分為以下 9 大類： 基礎地理圖層 (Foundation Geography) 社區特色與人文圖層 (Community & Culture) 生活機能圖層 (Daily Life & Amenities) 自然生態與景觀圖層 (Nature & Landscape) 議題導向圖層 (Issue-Oriented) 安全與防災圖層 (Safety & Disaster) 交通與路網圖層 (Transportation & Network) 發展與規劃圖層 (Development & Planning) 參與式資訊圖層 (Participatory Information) 次分類 (layer_subtype) 詳細列表 根據不同的 layer_type，以下是 layer_subtype 的詳細範例列表。您可以根據實際的專案需求（如大甲溪散步地圖）進行增減和調整。 1. 基礎地理圖層 (Foundation Geography) 這類圖層構成地圖的骨架，通常來自政府開放資料。 行政區界線：村里界、鄉鎮市區界、社里範圍 水系：河流、湖泊、水圳、滯洪池 地形：等高線、山坡地、坡向 土地利用：住宅區、商業區、農業區、工業區、公共設施用地 建物與地標：建築物、重要地標、門牌、POI (興趣點) 歷史影像：歷史航照圖、古地圖疊圖 2. 社區特色與人文圖層 (Community & Culture) 這類圖層展現地方的靈魂與記憶。 ...

什麼是「散步地圖」？ 在我們進行河流探索時，地圖不僅是導航的工具，更是一種「策展」的媒介。 散步地圖的核心概念，是透過地圖串聯更多的協力與情報，並利用群眾的移動軌跡描繪出有意義的資訊。這與我們強調的公私協力、開放資料精神不謀而合。 以下整理了散步地圖的核心價值與建構方法： 1. 目的與價值：為什麼要畫地圖？ 串聯協力：地圖是一個平台，能將分散的個人、店家、組織串聯起來，形成夥伴關係。 在地參與：鼓勵人們走出戶外，透過「走讀」產生對環境的直接關懷。 議題關注/績效評估： 透過地圖點出被忽視的「暗點」（如髒亂點、斷點）。 利用短網址 QRcode 追蹤使用率，評估活動成效。 商業與再生：人流即金流，散步活動能活絡在地經濟，推動地方再生。 2. 圖層解構：地圖裡該有什麼？ 散步地圖就像千層蛋糕，由不同屬性的圖層 (Layers) 堆疊而成： A. 基礎骨架 點 (Points)：具有意義的興趣點（POI），如古蹟、老樹、特色小店。 線 (Lines)：推薦的散步路徑、自行車道。 水 (Water)：重要的圳路圖資（幹線、支線），這在河流探索中尤為重要。 B. 情報層 (Information) 環境/生態： 水質監測點（清澈 vs 污染）。 生態庇護所、可下水的親水點。 維護管理： 清潔地圖：垃圾桶位置、髒亂點回報。 文史脈絡： 歷史古圳（如新竹隆恩圳、汀甫圳）的遺跡。 消失的河道。 C. 群眾層 (Crowdsourcing) 公民標記：結合 iNaturalist 或其他工具，讓參與者標記生態發現或垃圾熱點。 3. 如何開始？建構工具箱 🧰 Step 1: 資料收集 (Data Collection) 移動軌跡：利用手機 APP (如 Relive, Strava) 記錄散步路徑，匯出 GPX 格式。這是最真實的「路」。 圖像紀錄：使用開啟 GPS 定位的相機/手機拍照，確保照片帶有經緯度 (Geo-tagging)，方便後續展圖。 基礎圖資：下載政府開放資料（國土測繪中心 WMTS、水利署資料）。 Step 2: 呈現與分析 (Visualization) QGIS：最強大的開源 GIS 軟體，用來疊合上述所有資料。 Google My Maps：輕量級的展示工具，適合大眾導覽。 4. 實踐發想：從大新竹到大甲溪 我們可以嘗試將我們在「流域學校」或「大新竹區域」學到的經驗複製： ...