質心范諾圖法

使用范諾圖(Voronoi diagram) [7]是以產生漂亮的幾何形狀為出發點，這種方式產生 的圖形一定是凸多邊形，如此可避免利用人為的方式劃分出不自然的選區，並利用刻意

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

11

文的其中一個目的是希望把底層架構建置成一套函式庫以便進階使用者作二次開發。

2.3.1 ArcGIS Engine

ArcGIS Engine 是一個以開發客製化的 GIS 應用程式為主的產品。ArcGIS Engine 提供的應用程式開發介面(API)有 COM、C#、Java 和 C++。這些 API 能讓開發人員能更快 速的建置基於以 ArcGIS 為核心基礎的應用程式，ArcGIS Engine 包括一套建置 ArcGIS Desktop 產品基礎的核心元件。使用 ArcGIS Engine 可以建置獨立執行的應用程式或擴 充現有的應用程式，以提供有空間資料需求的 GIS 與非 GIS 用戶。

2.3.2 shape.net

shape.net[21]是一個開放在 sourceforge 的原始碼專案，程式碼是由 C#語言撰寫，原 本此專案是用來開啟標準格式的 shapefile 圖層檔案還有 dbf[19]格式的屬性表，一開始 會選shape.net 而非 ArcGIS Engine 主要是因為版權問題，還有 ArcGIS 系列並非開放原 始碼的軟體，即使是 ArcGIS Engine 也只提供使用者呼叫 API，並不能直接修改更底層 的程式碼，雖然 QGIS 也是開放原始碼的軟體但因為架構不如shape.net 精簡且繪製圖層 的效率也略輸 shape.net，最後再加上 C#編寫的程式有跨平台的特質所以我們選擇 shape.net 當作底層架購的核心，我們除了在 shape.net 上加入選區劃分的底層機制外，功 能方面還增加長寬比縮放、雙緩衝繪製、支援中文屬性表，進階的使用者可以利用我們 在shape.net 上加入選區劃分的底層機制快速開發選區劃分演算法。

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

12

第三章 系統架構

我們的系統架構主要是給開發者建置選區劃分的應用，開發者可以透過我們的系統得到 底層機制提供的支援，由於選區劃分的應用是建置在我們的系統之上所以開發者可以將 我們的系統架構視為上層應用的底層架構，我們的系統架構包含使用地理資訊系統作前 處理和程式集的建立這兩個部分，本章開始會先介紹整體概念再詳細介紹這兩部分，最 後再說系統架構的運作過程。

3.1 系統架構概觀

我們的系統包含兩個主要部分，第一部分：圖層前處理和第二部分：程式集的建立，

第一部分會牽涉到多個地理資訊系統的使用，而此部分主要的工作是檔案格式的轉換、

座標系統的轉換以及編碼的轉換，由於現有地理資訊系統已提供 此部分所有的功能所 以我們不必再自行開發，但是我們在第一部分的需求並沒有辦法單獨採用一套工具完成 且操作上不是那麼的直觀，所以我們推薦兩個在測試後最符合我們需求的工具: ArcGIS 和 QGIS，第一部分的工作只需做一次所以付出的人力成本並不大，第一部分的目的是 希望能避免使用非通用的文字檔案來記錄圖層，我們把此處的詳細操作過程放在附錄 一，在第二部分中我們需要自行編寫程式碼，而此部分主要的工作是整合shapefile 函式 庫、編寫底層機制的函式庫、編寫使用者介面、嵌入KML 標籤以及 Google earth COM API 的使用，第二部分的目的是希望未來想要介入選區劃分的研究者可以大幅度減少程式碼 的撰寫，而把精力放在核心的演算法上。

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

13

圖3.1 系統架構圖。

圖3.1 系統架構圖中有包含兩個部分的詳細流程，在這裡指的系統架構也就是建置 選區劃分應用的底層架構，其中region、polygon 和 arc 代表 coverage 的圖層，coverage 是ESRI 早期定義的向量檔案格式且和 shapefile 相比多了 topology，我們用圖 3.2 介紹 其中一種topology，我們可得知 polygon C 和 arc 2、arc4、arc9、arc6 相鄰，其他的 topology

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

14

例如: polygon-region 的 topology、arc-region 和的 topology 都會建置在底層機制中，細節 會在第四章說明，而region.shp、polygon.shp 和 arc.shp 是其轉成的 shapefile，矩形代表 一個功能，但是最後一項名為Google earth 的矩形不被包含在系統架構的兩個部分中，

這是因為Google earth 不是我們開發的，我們只是把選區劃分的結果交給 Google earth 作呈現，圖3.1 中 Part I 和 Part II 會分別在接下來的第一部分和第二部分說明。

圖3.2 polygon 和 arc 間的 topology。

第一部份

shapefile：勤崴村里界的圖層，檔案為 shapefile 格式

coverage：這是由勤崴村里界圖層經 ArcGIS 轉換而來，差別在於原本 shapefile 只有 region 圖層，而 coverage 有 region、polygon、arc 三個圖層

region.shp：經 coverage 轉回的 shapefile 檔，用 region 為單位，這裡的 region 可 對應到實體地圖的村里（此檔案和勤崴村里界的圖層一樣，只有檔名不同 polygon.shp：經 coverage 轉回的 shapefile 檔，用 polygon 為單位，這裡 polygon 可對應到實體地圖的單一多邊形（一個村里可由數個多邊形組成）

arc.shp：經 coverage 轉回的 shapefile 檔，用 arc 為單位，這裡的 arc 可對應到實 體地圖中兩個多邊形共用的線段

‧

transfer coordinate & encoding ：轉換三份shapefile的座標系統和屬性表編碼 KML：Google earth 接受的檔案格式，此檔案是由 region.shp 經 QGIS 轉換得到

第二部份

shapefile library & customized library：shapefile library 是讀取 shapefile 的函式庫，

此函式庫是 sourceforge 的一個專案並經過我們修改後的版本而 customized library 是包含選區劃分常用功能的函式庫也就是我們的底層機制

customized program：這裡是讓後續開發者套用選區劃分演算法的部分，唯一會 要後續開法者開發的部分

GUI：這裡是我們提供顯示地圖幾何形狀的功能以及預設的人機介面

KML tag program：把 KML 中每個村里依據選區著色，以便透過 Google earth 顯 示選區劃分的結果，屬於非即時顯示

Google earth COM API：可透過此 API 直接操作 Goole earth，屬於即時顯示

3.2 前處理

前處理會是利用地理資訊系統來處理圖層，會用到的工具有：ArcGIS 和 QGIS，

ArcGIS 在這裡主要的功能是把原始以 region 為圖層型態的 shapefile 輸出三份分別用 reion、polygon 和 arc 為圖層型態的 shapefile，依照圖 3.1 中的 Part I 可發現 ArcGIS 在輸 出這三份檔案時會產生coverage 檔案，會用到 coverage 的原因是因為它同時包含 reion、

polygon 和 arc 三種型態的圖層，不像 shapefile 只能使用其中之一作為圖層的型態，但 是我們也不能直接使用coverage 格式，因為此格式並不像 shapefile 被廣泛的使用，若使 用 coverage 格式我們就必須自行開發讀取 coverage 的程式，而且 QGIS 和圖 3.1 中的 shapefile 函式庫也將無法使用，意思是我們必須自行完成這些功能，故把 coverage 當作

‧

中間格式來產生三個採用不同圖層型態的shapefile 是最合乎成本的方法，再來我們會使 用QGIS 轉換座標系統、轉換編碼以及輸出 KML 檔案，轉換坐標系統其實可以在 ArcGIS 把原始shapefile 轉成 coverage 前做，這樣只要轉換一個檔案的座標系統而非三個檔案，

但是卻會讓ArcGIS 和 QGIS 交互使用，我們希望使用完一個工具後再使用下一個工具， Google earth 支援但是 ArcGIS 產生的 KMZ 並不包含標籤，也就是 shapefile 中的屬性表 無法嵌入在ArcGIS 產生的 KMZ 檔案中，所以此部分還是交由 QGIS 做，如此分配工作 我們可以利用QGIS 集中處理座標系統的轉換、編碼的轉換以及 KML 的輸出，ArcGIS 和QGIS 可以有明確且獨立的工作分配。

3.3 程式集建立

第二部分的工作是函式庫和圖形介面的建置，這部分的輸入是從第一部分輸出的 shapefile，而這部分會輸出結果至 Google earth，首先要讀取 shapefile，過去我們習慣先 用ArcGIS 將 shapefile 轉成文字檔再自行編寫讀取文字檔的程式

，由於原始shapefile 是二進制的格式若有依照其規則可以快速的讀取檔案，但是我 們從 ArcGIS 轉出的文字檔是 ANSI 編碼的文字檔，不像二進制的檔案可以直接複製到 對應的欄位，文字檔必須先抓到一群不含空白的連續字元當作token，並要辨識此 token 是為哪種型態的資料後才能放進對應的欄位，過去會讀取文字檔的原因是因為shapefile

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

17

的二進制規則複雜而且我們習慣只處理單一行政區，在這種情況下直接讀取文字檔並部 會造成太大的效能衝擊，但是我們這次想處理台灣所有選區數在二以上的一級行政區，

若要一一轉檔肯定是會花費額外時間且管理不便，過去我們有將文字檔序列化成二進制 檔案，雖然這樣可以大大減少讀檔的時間，但是此檔案只是我們自訂的一種二進制標準 並不是通用格式，接下來我們要介紹的是圖形介面，圖形介面分成兩個部分：基本幾何 的顯示和空照衛星圖，基本幾何是以 C#編寫的繪圖程式，這種顯示方式已能滿足大部 分的需求，過去我們都是採用此方式來顯示劃分後的選區，然而空照衛星圖就要仰賴 Google earth 資料庫中的影像，為了達成此目的有兩種做法: KML 標籤程式和 Google earth 的 COM API，KML 標籤程式是將我們已儲存好的結果對 KML 檔案中每個村里作 著色，然後會產生新的KML 並交由 Google earth 顯示著色的結果，Google earth 的 COM API 不必將結果先儲存也不必建立一張未著色的 KML 檔案，這樣可以直接顯示而省去 檔案匯入與匯出的時間，最後才執行記錄的動作，在產生新的選區劃分時是好的選擇，

但是有時我們只想觀看已產生的劃分結果而非產生新的選區劃分，那KML 標籤程式反 而是好的選擇。

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

18

3.4 系統運作流程

圖3.3 系統運作流程。

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

19

圖3.3 的系統運作流程指出在不同的開發階段的不同切入點，我們會解釋不同時機 分別要從系統架構的那些部分開始進行，首先我們要考慮產生新的選區劃分還是看過去 的劃分結果，若只是要看過去的劃分結果那只要透過 KML tag program 看歷史紀錄即 可，若要產生新的選區劃分則必須考慮是否有轉換過的圖層，若沒轉換過的圖層則必須

圖3.3 的系統運作流程指出在不同的開發階段的不同切入點，我們會解釋不同時機 分別要從系統架構的那些部分開始進行，首先我們要考慮產生新的選區劃分還是看過去 的劃分結果，若只是要看過去的劃分結果那只要透過 KML tag program 看歷史紀錄即 可，若要產生新的選區劃分則必須考慮是否有轉換過的圖層，若沒轉換過的圖層則必須