108 年 國立成功大學測量及空間資訊學系碩士班《地理資訊系統概論》

本題主要探討地理資訊系統中資料的表示模式、空間資料的精度定義及其對整合應用的影響。

核心觀念：

1. 空間資料模型：向量模型與網格（Raster）模型。
2. 空間資料精度：位置精度（Positional Accuracy）與屬性精度（Attribute Accuracy）。
3. 資料整合：精度對跨資料集整合的影響。

解題步驟：

(1) 同一現象（河流）的向量式與網格式描述及其差異：

• 向量式描述 (Vector Model)：

  • 概念：將地理現象表示為離散的幾何物件，如點、線、面。
  • 河流描述：河流通常被表示為線狀物件 (Line Features)。線由一系列連續的頂點 (vertices) 組成，每個頂點具有 X, Y 座標。
  • 記錄成果：
    • 座標序列：記錄河流的中心線或河岸線的頂點座標序列。
    • 拓撲關係：可以定義河流之間的連接關係（例如，支流匯入主流）。
    • 屬性：可以附加屬性，如河流名稱、長度、平均寬度、水質、流速等。
  • 優點：適合表示離散、邊界清晰的地理特徵，精度高，便於進行空間分析（如網絡分析、缓冲区分析）。

• 網格式描述 (Raster Model)：

  • 概念：將地理空間劃分為規則的網格（細胞或像素），每個細胞具有一個值，代表該細胞內該地理現象的屬性。
  • 河流描述：河流會被表示為一系列值為「河流」的細胞。
  • 記錄成果：
    • 細胞值：每個細胞的值代表該位置是否為河流（例如，值為 1 表示河流，值為 0 表示非河流）。
    • 空間解析度 (Resolution)：由細胞的大小決定，例如 10x10 公尺的細胞。
    • 地理配準 (Georeferencing)：需要定義網格的原點、方向和細胞大小，以便將其定位在地理空間中。
  • 優點：適合表示連續變化的現象（如高程、溫度、降雨量），便於進行影像處理和空間疊置分析。
  • 缺點：邊界不夠精確，表示線狀特徵時可能出現「樓梯狀」的鋸齒，精確的拓撲關係難以表達，檔案較大（取決於解析度）。

• 記錄成果的差異比較：

  • 精確度：向量模式能更精確地表示河流的幾何形狀和邊界。網格模式的精確度受限於細胞大小，河流邊界會呈現階梯狀。
  • 屬性表達：向量模式能直接附加多樣化的屬性；網格模式的屬性通常是單一數值（代表該現象是否存在或強度）。
  • 儲存空間：對於線狀特徵，向量模式通常比高解析度的網格模式更節省空間。
  • 分析類型：向量模式適合網絡分析、精確的面積計算；網格模式適合影像處理、機率分析、疊置分析。

本題主要探討台灣地理資訊共享平台 TGOS 的運作機制，以及在空間資料套疊時可能遇到的問題與解決方案。

核心觀念：

1. 地理資訊共享平台：TGOS 的目的、功能與架構。
2. 空間資料套疊 (Spatial Overlay)：資料整合的常見技術。
3. 套疊問題與解決：資料不一致性、投影系統差異、坐標系統差異等。

解題步驟：

(1) TGOS 促進跨領域地理資料分享與使用的機制：

TGOS（Taiwan Geospatial One Stop）是台灣的國家級地理資訊入口網站，旨在整合全國的地理空間資訊，提供統一的查詢、瀏覽、下載及應用介面，以促進地理資訊的共享與加值應用。其促進跨領域資料分享與使用的機制包括：

• 統一的資料目錄與標準：

  • TGOS 建立全國地理空間資料的目錄，讓使用者可以透過單一入口搜尋來自不同機關（中央部會、地方政府、學術機構等）的地理資料。
  • 推動地理資料的標準化（如採用 OGC 標準、國家標準），確保資料格式、詮釋資料（Metadata）的一致性，降低跨單位資料整合的技術門檻。

• 多樣化的服務介面：

  • 地圖服務 (Web Map Service, WMS)：提供地圖影像的串流服務，讓使用者無需下載資料，即可在網頁上瀏覽整合後的圖資。
  • 圖徵服務 (Web Feature Service, WFS)：提供地理物件（如點、線、面）的向量資料下載與編輯服務，方便進階分析。
  • 圖資下載平台：提供不同比例尺、不同主題的地圖圖資、數值地形模型 (DTM)、行政區界、土地利用等資料的下載。
  • API 介面：提供開發者介面，讓第三方應用程式可以串接 TGOS 的服務，開發創新的地理資訊應用。

• 跨領域資料整合與加值：

  • TGOS 匯集了來自不同領域（如國土、交通、水利、環境、防災、人口、經濟等）的地理資料，使用者可以透過 TGOS 平台方便地取得多來源的資料。
  • 透過標準化的服務，不同領域的資料可以更容易地進行空間套疊與關聯分析，從而產生新的知識與應用，例如：
    • 結合地質資料與土地利用資料，進行地質災害潛勢分析。
    • 結合人口分布與交通網絡，進行交通需求預測。
    • 結合環境監測資料與行政區界，進行區域環境評估。

• 資料品質與詮釋資料管理：

  • TGOS 鼓勵資料提供機關提供詳細的詮釋資料，說明資料的來源、更新頻率、精度、使用限制等，幫助使用者評估資料的適用性。
  • 透過推動資料標準，間接提升了資料品質的一致性。

(2) 套疊情形不理想的可能原因及解決方式：

套疊（Overlay）是 GIS 中將不同圖層空間疊置，分析它們之間空間關係的關鍵技術。若套疊情形不理想，可能表示資料之間存在不相容性，常見原因及解決方式如下：

• 原因一：坐標系統或投影系統不一致 (Inconsistent Coordinate/Projection Systems)
  • 說明：不同地理資料可能基於不同的地理坐標系統（如 WGS84、TWD97）或投影系統（如 TWD97 TM2 座標、經緯度）。若直接套疊，空間位置會錯位，導致套疊結果完全錯誤。
  • 解決方式：
    • 坐標轉換 (Coordinate Transformation)：將所有圖層轉換到同一套坐標系統。最常見的做法是將所有資料轉換到**國家測繪基點（TWD97）**或國際通用的 WGS84 系統。

核心觀念

本題考查「時空資料庫」與「地理資訊系統」的整合，重點包括：

1. 感測器位置屬於空間資料。
2. 感測值具有時間性，必須記錄觀測時間。
3. 感測器與觀測紀錄應分離設計，以避免重複儲存位置與設備資料。
4. 透過主鍵、外鍵建立資料表之間的關聯。
5. 利用條件查詢篩選特定時段，再以聚合函數計算平均值。
6. 將查詢結果與空間座標結合，轉換為地圖上的點、網格或分區圖層。

若第 $i$ 筆有效觀測值為 $x_i$，共有 $n$ 筆，則算術平均值為：

$$\bar{x}=\frac{1}{n}\sum_{i=1}^{n}x_i$$

若不同感測器分別計算平均值，則每一個感測器 $s$ 在指定時段的平均值為：

$$\bar{x}_s= \frac{\sum_{i \in s}x_i}{n_s}$$

其中 $n_s$ 是感測器 $s$ 在該時段內的有效觀測筆數。

---

解題方法一：資料表格設計

1. 感測器基本資料表

感測器資料表只記錄設備本身的固定資訊與位置：

欄位	說明
sensor_id	感測器唯一識別碼，主鍵
sensor_name	感測器名稱
sensor_type	感測器種類
unit	觀測單位，例如攝氏度、毫米
location	感測器空間位置
install_time	設置時間
status	啟用、停用或維修中

以關聯式資料庫表示如下：

CREATE TABLE sensor (
    sensor_id INTEGER PRIMARY KEY,
    sensor_name VARCHAR(100) NOT NULL,
    sensor_type VARCHAR(50) NOT NULL,
    unit VARCHAR(20) NOT NULL,
    location geometry(Point, 3826) NOT NULL,
    install_time TIMESTAMP,
    status VARCHAR(20) NOT NULL
);

location 使用點幾何資料型別，因為每一個感測器通常以一個地理位置表示。座標系統應統一，例如臺灣常用的 TWD97 / TM2 121 分區可使用 EPSG:3826。

---

2. 觀測資料表

觀測資料表記錄感測器在各個時間點所量測的數值：

欄位	說明
observation_id	觀測紀錄唯一識別碼，主鍵
sensor_id	對應感測器，外鍵
observed_at	觀測時間
value	觀測值
quality_flag	資料品質標記

CREATE TABLE observation (
    observation_id BIGSERIAL PRIMARY KEY,
    sensor_id INTEGER NOT NULL,
    observed_at TIMESTAMP NOT NULL,
    value NUMERIC NOT NULL,
    quality_flag VARCHAR(20) DEFAULT 'valid',

    CONSTRAINT fk_observation_sensor
        FOREIGN KEY (sensor_id)
        REFERENCES sensor(sensor_id)
);

感測器與觀測資料的關係為一對多：

$$\text{Sensor} \; 1 : N \; \text{Observation}$$

一個感測器可以產生許多筆觀測資料，但每一筆觀測資料只屬於一個感測器。

---

3. 觀測項目表

若系統同時收集溫度、濕度、雨量與空氣品質，宜將觀測項目獨立成表，避免將不同測量項目混在同一欄位中：

CREATE TABLE measurement_type (
    measurement_type_id INTEGER PRIMARY KEY,
    type_name VARCHAR(50) NOT NULL,
    unit VARCHAR(20) NOT NULL
);

觀測資料表加入觀測項目外鍵：

ALTER TABLE observation
ADD COLUMN measurement_type_id INTEGER NOT NULL;

ALTER TABLE observation
ADD CONSTRAINT fk_observation_measurement_type
FOREIGN KEY (measurement_type_id)
REFERENCES measurement_type(measurement_type_id);

完整關聯可表示為：

$$\text{Sensor} \; 1:N \; \text{Observation} \; N:1 \; \text{MeasurementType}$$

若不同感測器具有不同量測能力，還可增加感測器與觀測項目的對應表：

CREATE TABLE sensor_measurement_type (
    sensor_id INTEGER NOT NULL,
    measurement_type_id INTEGER NOT NULL,

    PRIMARY KEY (sensor_id, measurement_type_id),

    FOREIGN KEY (sensor_id)
        REFERENCES sensor(sensor_id),

    FOREIGN KEY (measurement_type_id)
        REFERENCES measurement_type(measurement_type_id)
);

---

4. 若要進行區域分析，可建立空間分區表

若成果需要以行政區、研究區域或規則網格呈現，可建立空間區域表：

CREATE TABLE study_area (
    area_id INTEGER PRIMARY KEY,
    area_name VARCHAR(100) NOT NULL,
    boundary geometry(Polygon, 3826) NOT NULL
);

感測器與區域之間不一定要直接儲存外鍵，因為可依空間關係由 ST_Within 或 ST_Intersects 判定。若區域歸屬固定，也可將 area_id 設為感測器的外鍵。

---

資料表設計原則

主鍵與外鍵

• sensor.sensor_id 是感測器資料表主鍵。
• observation.observation_id 是觀測資料表主鍵。
• observation.sensor_id 是參照 sensor.sensor_id 的外鍵。
• measurement_type_id 用來辨識觀測值的物理意義與單位。

如此可確保每筆觀測資料都能追溯至正確的感測器與觀測項目。

避免資料重複

感測器位置只儲存在 sensor 表中，不應在每筆觀測紀錄重複儲存經度與緯度。觀測資料只需記錄：

• 哪一個感測器；
• 哪一個時間；
• 哪一個觀測項目；
• 觀測值為何。

這符合資料庫正規化原則，也能避免感測器位置更新時產生不一致資料。

建立索引

大量感測器連續觀測會產生龐大資料量，因此應對常用查詢欄位建立索引：

CREATE INDEX idx_observation_sensor_time
ON observation(sensor_id, observed_at);

CREATE INDEX idx_observation_time
ON observation(observed_at);

CREATE INDEX idx_sensor_location
ON sensor
USING GIST(location);

其中：

• (sensor_id, observed_at) 適合查詢某感測器在特定時間的資料。
• observed_at 適合查詢整體區域的時間範圍。
• 空間索引適合查詢特定範圍內的感測器。

---

解題方法二：查詢特定時段並計算平均值

假設欲分析：

• 起始時間：民國 108 年 1 月 1 日 00:00；
• 結束時間：民國 108 年 1 月 2 日 00:00；
• 觀測項目為溫度；

本題主要探討如何利用地理資訊系統中的重分類 (Reclassification) 和空間分析工具，從多個圖層（DTM、河流、土地利用）中篩選出符合特定條件的地塊。

核心觀念：

1. 空間分析工具：緩衝區分析 (Buffer Analysis)、高程分析 (Elevation Analysis)、空間疊置 (Spatial Overlay)。
2. 重分類 (Reclassification)：將連續或離散的數值範圍轉換為新的類別。
3. 條件篩選：結合多個圖層的條件來識別感興趣的區域。

解題步驟：

此題的目標是找出符合以下所有條件的「公有土地」：

• 距離河岸 50 公尺以上
• 高度在海拔 100 公尺至 150 公尺之間
• 面積大於 500 平方公尺

我們將逐步處理這些條件，最終通過重分類將區域劃分為「符合」與「不符合」。

步驟一：處理「距離河岸 50 公尺以上」的條件

1. 輸入資料：河流圖層 (Line features)。
2. 操作：
   • 緩衝區分析 (Buffer Analysis)：對河流圖層執行 50 公尺的緩衝區分析。這會生成一個包含河流 50 公尺範圍內的區域。
   • 反轉緩衝區：我們需要「距離河岸 50 公尺以上」，這意味著我們要排除河流 50 公尺範圍內的區域。因此，需要將上述緩衝區圖層的範圍反轉。在 GIS 中，這通常可以透過「圖層代數 (Map Algebra)」或「空間查詢」來實現，例如，建立一個全區圖層，然後用全區圖層減去緩衝區圖層。
3. 輸出：一個新的網格或向量圖層，標示出「距離河岸 50 公尺以上」的區域。我們可以將此圖層的值重分類為：1 (符合)，0 (不符合)。

步驟二：處理「高度在海拔 100 及 150 公尺之間」的條件

1. 輸入資料：DTM 網格資料 (Raster, 10 公尺解析度)。
2. 操作：
   • 重分類 (Reclassification)：對 DTM 網格資料進行重分類。
     • 將海拔小於 100 公尺的區域歸為「不符合」。
     • 將海拔大於 150 公尺的區域歸為「不符合」。
     • 將海拔在 100 公尺至 150 公尺之間的區域歸為「符合」。
   • 輸出：一個新的網格圖層，標示出「高度在 100-150 公尺之間」的區域。重分類值：1 (符合)，0 (不符合)。

步驟三：處理「公有土地」的條件

1. 輸入資料：土地資料圖層 (Polygon features, 包含土地使用類別和所有權資訊)。
2. 操作：
   • 篩選 (Select By Attribute)：從土地資料圖層中，篩選出所有「所有權」為「公有」的土地多邊形。
   • 重分類：將篩選出的公有土地區域重分類為 1 (符合)，將非公有土地區域重分類為 0 (不符合)。
   • 輸出：一個新的網格或向量圖層，標示出「公有土地」的區域。重分類值：1 (符合)，0 (不符合)。

步驟四：疊置所有條件並進行最終篩選

現在我們有了三個二元圖層（值為 1 表示符合條件，0 表示不符合），分別代表：

• 圖層 A：距離河岸 50 公尺以上
• 圖層 B：高度在 100-150 公尺之間
• 圖層 C：公有土地

要找到同時滿足所有條件的區域，我們需要進行空間疊置分析，並將這三個圖層的值相加。

1. 操作：
   • 圖層代數 (Map Algebra) / 空間疊置 (Spatial Overlay)：將圖層 A, B, C 的值相加。
     • ResultGrid = LayerA + LayerB + LayerC
   • 重分類 (Final Reclassification)：
     • 如果 ResultGrid 中的某個單元格值等於 3 (表示 A=1, B=1, C=1)，則該區域同時滿足所有條件。將其重分類為「符合」。
     • 如果 ResultGrid 中的值小於 3，則表示至少有一個條件不滿足。將其重分類為「不符合」。

本題主要探討網路地理資訊系統 (Web GIS) 的運作架構以及重要的標準化服務，並分析其對整個應用環境發展的影響。

核心觀念：

1. Web GIS 架構：Client-Server 架構、元件。
2. 網路地圖服務標準：OGC 標準，WMS, WFS 的作用。
3. 標準化影響：互通性、互操作性、應用開發、資料共享。

解題步驟：

(1) 網路地圖服務的基本運作架構：

網路地理資訊系統 (Web GIS) 的運作主要採用用戶端-伺服器 (Client-Server) 架構。其基本運作架構包含以下幾個主要組成部分：

• 用戶端 (Client)：

  • 功能：這是使用者與 Web GIS 互動的介面，通常是網頁瀏覽器 (如 Chrome, Firefox) 或行動應用程式。
  • 組成：
    • 網頁瀏覽器/應用程式介面 (Browser/App UI)：顯示地圖、圖徵、屬性資訊，並接收使用者的操作指令（如縮放、平移、點擊、查詢）。
    • 前端腳本 (Frontend Scripting)：通常使用 JavaScript 配合 GIS 函式庫（如 Leaflet, OpenLayers, Mapbox GL JS, Google Maps API）來處理地圖的渲染、互動、圖徵的顯示和查詢請求的發送。
    • 地圖渲染引擎：負責在地圖畫布 (Canvas) 或 SVG 上繪製地圖瓦片 (Tiles) 或向量圖徵。

• 網路伺服器 (Web Server)：

  • 功能：負責接收來自用戶端的 HTTP 請求，並將請求轉發給後端的應用伺服器或 GIS 伺服器。同時，也負責將伺服器產生的回應（如地圖影像、JSON 資料）傳回給用戶端。
  • 常見軟體：Apache HTTP Server, Nginx。

• 應用伺服器/GIS 伺服器 (Application Server/GIS Server)：

  • 功能：這是 Web GIS 的核心處理單元。它接收來自網路伺服器的請求，解析請求中的地理空間資訊，調用相關的 GIS 功能（如空間查詢、空間分析、地圖渲染、資料庫存取），然後生成回應。
  • 組成：
    • GIS 引擎/函式庫：包含各種 GIS 處理能力，如空間數據處理、空間分析、地圖製圖。
    • 伺服端腳本/應用程式：例如使用 Python (Django/Flask), Java (Spring), C# (.NET) 編寫的後端應用程式，它們負責處理業務邏輯和調用 GIS 功能。
    • 地圖服務接口 (Map Service Interface)：實現特定的網路地圖服務標準（如 WMS, WFS），以標準化的方式提供地圖和圖徵數據。

• 資料庫管理系統 (Database Management System, DBMS)：

  • 功能：儲存地理空間資料（如向量圖徵、網格資料、屬性資料）和非空間資料。
  • 組成：
    • 空間資料庫：如 PostgreSQL with PostGIS, Oracle Spatial, SQL Server Spatial，它們支持空間數據類型和空間索引。
    • 傳統資料庫：用於儲存非空間屬性資料。
  • GIS 伺服器：透過資料庫連接器 (ODBC, JDBC) 或特定的資料庫 API 存取資料。

運作流程範例 (請求一張地圖)：

1. 使用者在瀏覽器中操作（如縮放地圖），用戶端 (JavaScript) 產生一個 HTTP 請求，指定所需的區域、比例尺、地圖服務類型（如 WMS）。
2. 請求通過網路伺服器，傳送到 GIS 伺服器。
3. GIS 伺服器解析請求，從資料庫中讀取對應的地理空間資料。
4. GIS 伺服器根據請求，將資料渲染成地圖影像（如 JPEG, PNG 格式的瓦片），或直接傳送向量圖徵資料。
5. GIS 伺服器將產生的地圖影像或圖徵資料傳回給網路伺服器。
6. 網路伺服器將回應傳回給用戶端瀏覽器。
7. 瀏覽器的 JavaScript 接收到地圖影像或圖徵資料，並在地圖畫布上顯示出來。

(2) 網路地圖服務標準的角色與影響：