事件導向地理資訊系統－以交通大學光復校區為例

國 立 交 通 大 學

土 木 工 程 學 系

碩 士 論 文

事件導向地理資訊系統－以交通大學光復校區為例

Event-driven GIS: a case study of Kuang-Fu

Campus, National Chiao-Tung University

研 究 生：紀凱程

指導教授：史天元

事件導向地理資訊系統－以交通大學光復校區為例

Event-driven GIS: a case study of Kuang-Fu Campus, National

Chiao-Tung University

研 究 生：紀凱程 Student：Kai-Cheng Chi

指導教授：史天元

Advisor : Tian-Yuan Shih

國 立 交 通 大 學

土 木 工 程 學 系

碩 士 論 文

A Thesis

Submitted to Department of Civil Engineering

College of Engineering

National Chiao-Tung University

in partial Fulfillment of the Requirements

for the Degree of Master

in

Civil Engineering

July 2010

Hsinchu, Taiwan, Republic of China

事件導向地理資訊系統－以交通大學光復校區為例

學生：紀凱程

指導教授：史天元

國立交通大學土木工程學系

摘要

校園事件的紀錄以文字訊息表述，訊息中隱含空間資訊，開放式地理空間協會(Open Geospatial Consortium, OGC)的空間連結資料存取服務(Geolinked Data Access Service, GDAS) 提出以空間 ID(Geolink id)做為該區域屬性之索引。本研究利用 GDAS 概念，將校園事件以發 布單位及教室定位，利用混搭地圖 API 配合由交通大學提供資料庫，建置交通大學光復校區 之事件導向地理資訊系統，使用者能依地點與時間查詢校園事件。 本研究先比較三類地圖 API，入口網站、商用軟體與自由軟體地圖 API，以提供圖層及 支援功能為選擇考量，搭配事件資料庫建置混搭系統。分析現有系統發現校園事件發生地點 寫入於內容中，不利定義空間位置。定義事件發生地點欄位，以辦公室/教室為校園空間框架 最小單元，賦予空間 ID，事件紀錄時間以分(minute)紀錄，設計校園事件資料表，整合各種 類校園事件。 本研究設計校園事件發布流程圖，將校園事件歸類為二類，一類是沒有事件發生地點的 「新聞」(News)，一類是有事件發生地點的「實地事件」(Events with exact location)，定義實 地事件發生為一次/多次/多地/多時地事件並設計發布表，利用此流程圖工作方式可將各類型 校園事件發布。

Event-driven GIS: a case study of Kuang-Fu Campus,

National Chiao-Tung University

Student : Kai-Cheng Chi

Advisor : Tian-Yuan Shih

Department of Civil Engineering

National Chiao Tung University

Abstract

Events around the campus recorded by text, space information imply in themselves. Geolinked Data Access Service (GDAS), a discussion paper proposed by Open Geospatial Consortium (OGC), suggests a way to publish and access data that refers to spatial features (Geolink id). This study uses the concept of GDAS, locates the spatial position by announced sectors and classrooms, uses the map API (Application Program Interface) and event databases provided by NCTU, builds an event-driven GIS by mashup techniques. Clients can query events by specifying location and time.

This study compares three types of map API, portal, business software and opensource map API, choosing from its base layer and supporting functions. Analysis found that the existing system records location in event’s main article and is not helpful to locate the event place. Therefore defines the recoding column, Geospatial ID for every office/ classroom, represents the smallest unit on campus. The event’s recording time suggest to the minute level. Using Geospatial ID and time to design the event information table on campus, trying to integrate a variety of classes on campus events.

The study designs workflow chart to release campus events, campus events will be classified as two types, one class where the event location is null called "News ", the other class where the

event’s location is accurate called "Events with exact location ". Defines events with exact location for once/multiple/multiplace/multi-time-and-place events, and design a table to distinguish them. Use this flowchart campus events can be released.

致謝

剛踏入研究所的大門，那時已經 25 歲。當過兵，也做了一陣子工作，重拾書本的感覺是 既期待又怕受傷害。還好有許多朋友們相挺，老師們孜孜不倦的教誨，學長姊指導，學弟妹 切磋討論跟帶助教時的可愛大學生們，讓我覺得時間過得好快，一閃眼又到了第二個夏天， 也是我準備離開交大的時候了！ 不可避免的，要寫長長的感謝清單，首先感謝口試委員林峰田教授、蔡博文教授和陳繼 藩教授的熱心指正並提供寶貴意見，使本論文得以更加完整。再來要感謝指導老師史天元教 授，老師指導我如何做研究，常常撥空提點論文方向，才能順利畢業。再來是實驗室的大家 庭，進金學長、偉城學長、小光、歷韋哥哥、大學同學到現在變成博士哥的俊毅、雅信、翊 如、芳諭、沐崧、佳筠、暐尊；張智安老師及實驗室崇軒、信瑜；結構組好朋友：親愛的表 弟彥(緣分讓我們一起念交大土木所)、凱平、宗輝、小古、小丁、靖瑜博士哥；樓下黃老師 實驗室：貓哥、亨利博士哥、彥杕、恩銘、逸如、千惠、洵頡、美芳、鐙凱。給我指導意見 的子銘學長、思偉學長、中研院林農堯兄。 哇…還沒說完，還有最愛的父母，妹子，狗狗，表姊郁媛，阿姑們，念個書覺得跟家人 的關係也越來越好了喔！～謝謝守護我的親朋好友，我要畢業啦！感謝你們～還有還有土地 公，念書的時候去拜了好幾回，很有效的呢！

目錄

摘要 ... I Abstract ... II 致謝 ... IV 目錄 ... V 圖目錄 ... VII 表目錄 ... IX 第一章 緒論 ... 1 1.1 研究動機與目的 ... 1 1.2 研究方法與研究流程 ... 2 1.3 前人研究 ... 3 1.4 論文架構 ... 3 第二章 文獻回顧 ... 5 2.1 Web2.0 ... 5 2.1.1 Web 2.0 緣起 ... 5 2.1.2 訊息來源(Feed) ... 7 2.2 Ajax ... 7 2.2.1 Ajax 的規範與傳統網路傳輸型態比較 ... 8 2.2.2 Ajax 優缺點與處理方式 ... 9 2.2.3 Ajax 資料傳遞方式 ... 10 2.3 WebGIS ... 14

2.3.1 CGI(Common Gateway Interface) ... 15

2.3.2 ActiveX ... 15 2.3.3 Java Applet ... 16 2.3.4 Java Servlet ... 17 2.3.5 OpenGIS... 17 2.4 GDAS 與 GLS ... 18 2.4.1 GDAS ... 18 2.4.2 GLS ... 19 第三章 混搭與地圖 API 探討 ... 22 3.1 混搭與地圖混搭 ... 22 3.1.1 伺服器端混搭 ... 22 3.1.2 用戶端混搭 ... 24

3.2 API(Application Program Interface) ... 25

3.3 網路地圖 API(Web Map API)比較 ... 26

3.3.1 入口網站提供的 Map API ... 26

3.3.2 商用軟體 ESRI 提供的 Map API－ArcGIS API for JavaScript ... 30

3.3.3 自由軟體提供的 Map API－OpenLayers... 32

3.3.4 小結 ... 33

3.4 地圖 API 混搭開發的 WebGIS 與套裝 WebGIS 比較 ... 35

3.5 Google Maps API V2 版本建置方式 ... 36

第四章 交通大學光復校區事件導向地理資訊系統建置 ... 39 4.1 事件導向地理資訊系統 ... 39 4.2 交通大學事件導向地理資訊系統 ... 39 4.3 交通大學校園事件資料庫 ... 40 4.4 建置交通大學校內地標資料表與面圖徵資料 ... 42 4.5 系統設計與建置 ... 43 4.5.1 系統規格與架構 ... 43 4.5.2 設計系統資料表與空間對應關係 ... 44 4.5.3 系統查詢設計與建置 ... 45 4.5.4 搜尋附近區域功能的校園事件導向地理資訊系統 ... 46 4.5.5 校園事件實體關聯模型(Entity-Relation Model) ... 48 4.5.6 小結 ... 49 4.6 設計交通大學事件導向地理資訊系統事件資料表與應用面向 ... 52 4.6.1 定義新聞與實地事件 ... 52 4.6.2 定義校園空間欄位 ... 52 4.6.3 定義事件發生時間地點互動與事件類型 ... 53 4.6.4 校園事件資料表架構 ... 55 4.6.5 校園事件資料表與交通大學事件提供事件資料比較 ... 56 4.6.6 利用校園事件資料表整合校園資訊與應用 ... 57 4.7 校園事件發布流程 ... 58 4.8 校園事件資料表應用於地理資訊 ... 59 第五章 結論與建議 ... 61 參考文獻 ... 63 附錄一 利用 Dapper 讀取公共事務委員會新聞 ... 66 附錄二 利用 RSS 資訊寫入資料庫 ... 68 附錄三 利用 ASP.net 將空間資料呈現於圖台 ... 72 附錄四 事件導向地理資訊系統使用評估 ... 78

圖目錄

圖 1- 1 研究流程 ... 2 圖 2- 1 Web2.0 示意圖 ... 6 圖 2- 2 傳統網路架構(Garrett, 2005) ... 9 圖 2- 3 Ajax網路架構(Garrett, 2005) ... 9 圖 2- 4 HTML文件的DOM結構樹(W3C)... 10 圖 2- 5 DOM型態的WebGIS－Catagen.org ... 11 圖 2- 6 XML資料範例(廖信彥，2007) ... 12 圖 2- 7 XSD資料範例(廖信彥，2007) ... 12 圖 2- 8 JSON資料(廖信彥，2007) ... 13 圖 2- 9 WebGIS架構示意圖(Painho et al, 2001) ... 14 圖 2- 10 CGI運作流程(黎翰林，1999) ... 15 圖 2- 11 CGI呼叫程式執行功能 ... 15 圖 2- 12 Java Servlet的生命週期 ... 17 圖 2- 13 GLS工作示意圖，呼叫GDAS與圖徵資料(OGC, 2004) ... 20 圖 3- 1 伺服器端混搭 ... 23 圖 3- 2 用戶端混搭 ... 24

圖 3- 3(a) programmableweb對API進行的分類 (b) 廠商投稿至programmable web ... 25

圖 3- 4 Bing Maps在交通大學空照影像 ... 26

圖 3- 5 Google Maps在交通大學空照影像 ... 27

圖 3- 6(a) Yahoo!Maps (b) Yahoo!地圖在交通大學光復校區向量圖 ... 28

圖 3- 7 Yahoo!Maps/地圖在新竹地區衛星影像 ... 28

圖 3- 8 ArcGIS Server提供的地理資訊處理服務(Geoprocessing Service) ... 31

圖 3- 9 以ArcGIS API for JavaScipt開發的台灣等溫面圖 ... 31

圖 3- 10 以OpenLayers展示台灣地區SRTM高程圖 ... 33 圖 3- 11(a) 交大全部單位地標(左) (b) 交大地標(右上) (c) 交大訊息地圖(右下) ... 38 圖 4- 1 時間、空間、屬性三者關係(Ott, 2001) ... 39 圖 4- 2 校園課程資料檢視表 ... 40 圖 4- 3 以Dapper掃描交通大學公共事務委員會發布新聞... 41 圖 4- 4(a) 校內地標點位資料 (b) 校內建物面圖徵資料 ... 42 圖 4- 5 利用交通大學網路電話簿系統建立校內一二級單位空間對照 ... 43 圖 4- 6 交通大學校園事件導向地理資訊系統架構圖 ... 43 圖 4- 7 交通大學校園事件導向地理資訊系統運作流程圖 ... 44 圖 4- 8 LocationFindCourse資料表對應關聯圖 ... 44 圖 4- 9 Location_find_event資料表對應關聯圖 ... 45 圖 4- 10 以[星期幾]與[校園大樓]查詢課程 ... 45 圖 4- 11 以[校園大樓]、[起始日期]，[結束日期]查詢活動 ... 46

圖 4- 12(a) 建立信息寫入頁面 (b) 地理信息讀取頁面 ... 46 圖 4- 13 搜尋設定地標範圍 ... 47 圖 4- 14 搜尋附近區域事件 ... 47 圖 4- 15 實體關聯模型示意 ... 48 圖 4- 16 校園事件實體關聯模型 ... 49 圖 4- 17 新聞 ... 51 圖 4- 18 實地事件 ... 51 圖 4- 19 校園新聞登錄表 ... 52 圖 4- 20(a) 校園空間資料表 (b) 為空間實體對應的教室代碼 ... 53 圖 4- 21 實地事件登錄表 ... 54 圖 4- 22 事件地點時間表 ... 54 圖 4- 23 實地事件資料表 ... 55 圖 4- 24 事件寫入時間約制條件 ... 56 圖 4- 25 校園事件發布流程 ... 59 圖附錄一- 1 以Dapper掃描公共事務委員會網站 ... 66 圖附錄一- 2 調整RSS發布欄位及名稱 ... 67

圖附錄一-3(a) Dapper輸出格式 (b) Dapper掃描結果嵌入於網頁(紅框處) ... 67

圖附錄二- 1 校園公告RSS內容，計四個item，紅框處為該item內容 ... 68 圖附錄二- 2 取得校園公告各類別RSS連結 ... 69 圖附錄二- 3 將各類RSS連結輸入至Yahoo!Pipes，產生整合RSS資訊 ... 69 圖附錄二- 4 利用Yahoo!Pipes發布RSS ... 70 圖附錄二- 5 利用Access讀取RSS資料 ... 70 圖附錄二- 6 設定各欄位類型，寫入Access ... 70 圖附錄二- 7(a) 執行Access檔案匯入工作 (b) 匯入成果預覽 ... 71 圖附錄三- 1 調整圖徵幾何與內容 ... 72 圖附錄三- 2 呼叫Google Map程式碼 ... 73 圖附錄三- 3 呼叫地圖控制項 ... 74 圖附錄三- 4 疊合圖層檔案程式碼 ... 74 圖附錄三- 5 VS2008 編輯ASP.net圖示，紅框為Button元件，藍框為div元件 ... 75 圖附錄三- 6 以C#指令讀取SQL Server資料庫 ... 76 圖附錄三- 7 以C#將資料寫入ASP.net頁面 ... 76 圖附錄三- 8 ASP.net與JavaScript互動程式碼 ... 77

表目錄

表 3- 1 入口網站提供的Web Map API比較 ... 29

表 3- 2 地圖API比較 ... 34

表 3- 3 本研究使用Google Maps API函式 ... 37

第一章 緒論

1.1 研究動機與目的

地理資訊能夠表達物件在空間中的位置與其他物件的位相關係(Topology Relationship)。 文字訊息加入空間參考位置後，能使物件的描述具體化。故地理資訊對於加強文字訊息傳遞 有很大的幫助。使用地圖 API 混搭的網路地理資訊系統，操作簡單，速度快，能提供空間資 訊。 交通大學有三個主要的信息發布平台，分別是教務處課務組的選課系統、聯合服務中心 的校園公告系統，及公共事務委員會校園新聞，使用者可以透過網路搜尋課程、活動與最新 消息。這些訊息與事件發生地點是以文字敘述的，我們只能從地圖上去尋找事件發生在何處。 若能將事件發生的地點與時間呈現於地圖上，可了解事件發生位置，也能從事件與時空互動 的觀點描述事件間的相位關係。

開放式地理空間協會(Open Geospatial Consortium, OGC)在 2004 年提出 GDAS(Geolinked Data Access Service)，將屬性與空間框架結合，成為地理連接資料(Geolinked Data)，應用層 面廣泛：如與 GLS(GeoLinking Service)配合產製主題圖(Canadian Geospatial Data Infrastructure, CGDI ,2004)、匯出地理連接資料供 GIS 軟體分析，或註冊至伺服器成為 GDAS 提供者等應 用面向。

校園事件導向地理資訊系統概念相同於 GDAS，想要將校園事件以空間資訊型態呈現在 網際網路，利用地點與時間搜尋事件內容。配合混搭技術，將事件資料定位至地圖，加強訊 息傳遞能力。

1.2 研究方法與研究流程

本研究分為二部分，地圖 API 的比較，及校園事件導向地理資訊系統實作。地圖 API 比 較三種不同的地圖 API，類別為入口網站、商用軟體，與自由軟體，就支援功能與研究區衛 星影像選擇適合本研究使用的地圖 API。 第二部分為建置交通大學光復校區事件導向地理資訊系統，空間框架以光復校區校舍大 樓定位，事件資料庫以交通大學提供之課程資料、聯合服務中心校園公告資料，與公共事務 委員會提供新聞資料為來源。以混搭技術將地圖 API 配合事件資料庫建置系統。由建置結果 分析校園事件，提出校園事件資料表設計方式，與該資料表能結合的事件內容，利用此資料 表作為校園事件導向地理資訊系統之資料參照。 下圖 1-1 為本研究流程圖： 地圖API選用 課程資料 聯合服務中心資料 公共事務委員會資料 校園事件導向地理 資訊系統 設計校園事件 資料表 設計校園事件 發布流程 圖 1- 1 研究流程    

1.3 前人研究

本研究以混搭技術建立事件導向地理資訊系統，混搭技術是目前建置 WebGIS 的熱門方 向，陳詠霖(2008)提出利用網路相簿、天氣預報，地圖等 API 設計一個混搭網頁程式，使用 者能在地圖上點選 POI 時，帶出該地區景點資訊、相簿內容與當地氣候，並且以 Web 2.0 方 式讓使用者能建立新的 POI。李俊銘(2008)利用即時公車行駛資訊，設計公車轉乘系統，實 現公車即時路徑規劃服務，混搭地圖 API 為 OpenLayers。 在事件導向部分，本研究預期建立交通大學事件導向地理資訊系統，目的結合事件與空 間位置，在 2004 年，OGC 提出了 GDAS 與 GLS 0.9.1 版的提案，紀錄空間位置的屬性值， 例如氣溫、雨量等，將這些資料以賦予空間 ID(Geolink id)，在空間將屬性資料定位，成為地 理連接資料(Geolinked Data)。空間 ID 對應的是 GLS 的圖徵資料，可以是點圖徵如測站，線 圖徵如河流，面圖徵如行政區。GDAS 的空間連接資料能與 GLS 連接，由 GLS 發布帶有屬 性的圖徵資料，或在註冊中心註冊 GDAS，利用空間 ID 再串組其他 GDAS 的資料，供後續 資料連接(CGDI, 2004)。GDAS 搭配 GLS 與主題圖伺服器，由使用者提供的屬性資料配合產 製主題圖資(林士裕，2005)。 校園事件部分，Tseng-Chyan(2007)提出及時事件地理資訊服務(Timely-Event GIService) 建置設計，以人、事、時，地四個面向設計校園資訊整合系統。從使用者登入網頁後，由日 期尋找國定假日、假日，上課日三種時間類別，抓取該日期類別內的事件資料。 本系統開發以交通大學提供之資料庫，以混搭方式建置事件導向地理資訊系統，利用 GDAS 概念，將事件資料以發布單位及上課教室定位。從已完成的系統再分析校園事件，設 計校園事件資料表填表方式與發布校園事件流程。

1.4 論文架構

本論文架構共分為五章，各章主題說明如下： 第一章 緒論：敘述前言研究動機與目的，研究方法與論文架構。

第二章 文獻回顧：回顧網路技術發展、資料傳遞格式、WebGIS 技術演進，及 OGC 提 案 GDAS 與 GLS。

第三章 混搭與地圖 API 探討：定義混搭與 API，比較目前使用率高的地圖 API，探討功 能與限制，為後續地圖混搭應用。

第四章 交通大學光復校區事件導向地理資訊系統建置：以現有校園事件資料庫混搭地圖 API 建置系統，並提出校園事件發布流程。

第二章 文獻回顧

本研究利用混搭技術開發 WebGIS 應用系統，由網路結構為始探討 Web 1.0 轉型至 Web 2.0，資料的提供由網站轉型為平台，網路使用者也是資料提供者。資料在 Web2.0 時代的傳 遞透過目前主流的交換格式為 XML，另一發展主流為輕量化檔案傳輸格式－JSON。

WebGIS 開發技術演進，在本章 2.3 節進行論述。2.4 節討論 GDAS 與 GLS，為 OGC 正 在提倡的服務標準，利用空間 ID 連結屬性，成為具有屬性圖徵的資料，GDAS 與 GLS 標準 應用為 HTML 展示屬性資料、以 XML 傳遞屬性資料與其他 GDAS 連結，達成空間資料分享 目的。

2.1 Web2.0

2.1.1 Web 2.0 緣起

Web 2.0 是 O’Reilly 公司與 MediaLive 公司在 2004 年一場會議中提出的名詞。1990 年代 網際網路以.com 為主，在網路泡沫化之際，存活下來與發展良好的公司在資料的處理模式有 共通點，是網路使用者的知識及資料越形重要。網路公司也從獨自擁有資料的大公司轉型成 網路使用者參與資料提供的整合平台。以前網路使用者要發行資料，必須自己架設網站才能 分享，現在只要在社群網站(Yahoo，Google，MySpace 等)申請帳號，就能開始寫自己的 Blog。 Web 2.0 不是新技術，是當代網際網路技術的總稱，包含了群眾參與和傳輸技術的演進。 在圖 2-1 內容中，列出符合 Web 2.0 的標準，具備其中一些標準就可以稱為 Web 2.0 概念的網 站。

圖 2- 1 Web2.0 示意圖 依 O’Reilly 建議，Web 2.0 應該要有以下特徵(2005)： 1. 以網際網路為平台：網站變成一個資訊整合平台，不是單一的資訊提供者，例如 Blog 提供商。 2. 使用集體智慧：利用使用者的資料與互信編輯網路內容，如維基百科(Wikipedia)， 或拍賣網站，建立買賣互評機制，以評價作為網路消費參考資訊。

3. 數據是下一個「Intel Inside」：網路世界，擁有最多資料，代表更多營業商機。Google 以混搭方式讓使用者能簡單的將資料展示到網路上，數據的增加量快速。 4. 網路程式不停更新：網路使用者以瀏覽器上網，網頁的動態程式語言包括 ASP、JSP、 PHP 等，或是利用外掛(Plug-in)如 Flash，Silverlight 等，軟體的更新都在背後的腳本中， 軟體無時不刻在更新，只要使用者按下更新網頁，就得到新版本的網頁及服務。 5. 輕量化程式模型：以 XML 撰寫的資料存取協定如 RSS，Atom，有限定的架構，網 路資料在固定規範中撰寫，用意是快速讀取。網路傳輸協定如 REST(REpresentational State Transfer)及 SOAP(Simple Object Access Protocal)，讓 Web Service 有共通的傳輸協定， 在同一語言下網路程式可互相叫用，加速資料傳遞。另一類傳輸技術如 Ajax，可更新部 分新資料，大幅減少資料重複傳遞。

6. 軟體超越單一設備：在不同平台能使用相同的服務，O’Reilly 提出一個範例-iTunes。 使用者用個人電腦連結到 iTunes 購買音樂，或使用 iPhone，iPod，iPad，都能連到同一 個網路平台，讓購買方式超越設備。 7. 豐富的用戶體驗：動態網頁語言 DHTML、文件物件模型(DOM，Document Object Model)、XML、XmlHTTPRequest，JavaScript 等技術綜合為 Ajax 非同步傳輸技術，讓 網路能更快速的傳遞內容。另一部分是使用者的參與，像 Skype，使用者提供一部分頻 寬支持語音電話，讓通訊更加順暢。 2.1.2 訊息來源(Feed)

Feed 指的是資料來源，網站透過發布 Feed 方式將最新資訊綱要傳遞給客戶。使用 Feed 最多的是新聞網站業者與網誌業者，網站將更新後的內容以 Feed 方式傳給使用者，使用者可 利用閱讀器訂閱網站提供的 Feed。

常用的 Feed 格式有 RSS(Really Simple Syndication)與 Atom(Atom syndication format)兩種， 使用者在網站訂閱這類 Feed 就可透過閱讀器觀看最新的綱要。 RSS 是 XML 的延伸應用，設計架構必須符合 XML 的規範，但 RSS 有限定標籤以利程 式讀取，不能自訂標籤定義。Atom 是基於 RSS 設計經驗後，規定更為嚴謹的 XML 格式， 例如 RSS 標籤<description>能描述全文或摘要；Atom 分類較嚴謹，利用<summary>描述摘要、 <content>描述內文。

2.2 Ajax

Ajax 全名是 Asynchronous JavaScript And XML，指的是非同步傳輸技術，首見於 2005 年 2 月，由 Jesse James Garrett 提出。運用在網頁架構，以往網路資料的處理方式是伺服器必 須處理整個網頁的內容，再回傳給使用者，此類方式造成未更新的資料也重複回傳，造成流 量浪費。Ajax 的處理方式是：將網頁中需要更新的部分傳給伺服器來處理。如 Google Suggest， 使用者鍵入部分資訊就開始在伺服器搜尋可能的資料，將可能的結果顯示。另一個應用例就 是 Google Map，移動及放大縮小即時進行，不需要重新整理網頁。提升了網頁的回應速度與

互動性。

2.2.1 Ajax 的規範與傳統網路傳輸型態比較

Ajax 規範有以下幾點：

1. 用 W3C 規範的 CSS 和 XTML 來定義網頁外觀。

2. 使用 DOM 來定義網頁元素，及 DHTML 呈現動態內容。

3. 用 XMLHttpRequest 或 XMLHTTP(微軟 Internet Explorer 的 ActiveX 物件)來解析與 處理非同步資料。 4. 使用 XML 進行資料交換，使用 XSLT 來轉換 XML 格式資料。 5. 用 JavaScript 控制前述的內容。 傳統網路應用圖 2-2 與 Ajax 架構圖 2-3 比較可見 Ajax 在傳統瀏覽器與伺服器間，還多 了一個處理 Ajax 訊息的引擎，安裝在瀏覽器端。Ajax 運作週期如下： 1. 對瀏覽器輸入資訊，輸入文字，按下按鈕，或是拖曳滑鼠。 2. 輸入的指令會轉換成 JavaScript 物件或函式，呼叫相關的程序傳給 Ajax 引擎。 3. Ajax 引擎對伺服器發出 XMLHttpRequest，在處理新的 XMLHttpRequest 時， JavaScript 的函式呼叫已經開始回傳，這種過程就是非同步傳遞。而 Ajax 引擎得到伺服 器的 HttpResponse 時，Ajax 引擎會呼叫對應的函式在瀏覽器使用者介面反應。

圖 2- 2 傳統網路架構(Garrett, 2005) 圖 2- 3 Ajax 網路架構(Garrett, 2005) 2.2.2 Ajax 優缺點與處理方式 Ajax 的優點能在不更新整個頁面的前提下提供資料，對於使用者而言，更新部分的內容， 不需重整整個網頁能讓等待的時間大幅降低，增加瀏覽時的效率；對於網站業者，更新部分 的內容能避免多次傳送幾乎相同的內容給使用者，降低網站伺服器負擔。

Ajax 的缺點有以下二點：

1. 由於 Ajax 包括樣式控制表(CSS)、文件物件模型(DOM)及 JavaScript，目前各瀏覽器 商支援程度不盡相同，程式設計可能要先解決不同瀏覽器間相容性，而不是處理程式本 身。為解決此問題，有業者專門開發通用的 Ajax 函式庫或架構，開發商會先針對各個瀏 覽器測試，確保開發的功能在各瀏覽器都能運作，使用者或開發商再利用通用函式庫撰 寫網頁程式，讓各瀏覽器皆能正常作用，例如 jQuery 函式庫。

2. Ajax 一次只更新一部分資料，沒有「上一頁」，「下一頁」的概念，目前有一些 JavaScript Library 有開發此類功能函式庫，如 RSH(Really Simple History)及 jQuery。或在網頁開發 時，利用 iFrame 隱藏框架記錄最近幾次瀏覽資訊，或使用錨點(網址中的#符號)記錄前幾 次瀏覽的狀態，以實現上下頁功能。

2.2.3 Ajax 資料傳遞方式

非同步傳遞方法涉及資料交換，資料交換以通用標準語言傳遞，例如 XML 與 JSON，利 用程序解譯資料以 DOM 物件存取，以便進行存取解析。以下對 DOM 與 XML、JSON 此二 種交換格式作介紹：

1. DOM：文件物件模型(Document Object Model，DOM)，為跨平台與跨語言的界面， 動態網頁中每個標籤相當於一個節點，這些節點由下往上對應到整份網頁文件，有著樹 狀的結構，如圖 2-4 所示。

DOM是動態網頁的基礎，目前Cartagen(http://cartagen.org/)利用HTML5 技術，將地物視 為物件，伺服器利用GeoJSON格式將所有地物呈現於地圖上，使用者瀏覽器利用 GSS(Geographic Style Sheet) 繪製地物樣式，採用此種方式能讓使用者端電腦進行地物繪 圖，而不需透過網站伺服器將地物上色，降低伺服器負擔。Catagen.org展現如下圖 2-5 所示。

圖 2- 5 DOM 型態的 WebGIS－Catagen.org

圖上的黑色單元是一個物件，能對此物件進行透明度調整，下載地物資料操作。 Cartagen.org 的出現顯示 WebGIS 在 HTML5 時代有可能發展為 DOM 型態。

2. XML：XML(eXtensible Markup Language)，可擴展標示語言。1.0 標準在 1998 年推 出，1.0 標準在 2008 年修訂為第五版，1.1 標準在 2006 年修訂為第二版。XML 定義資料 與資料結構的方式，目的在不同系統與應用程式之間交換資料，XML 資料標籤的內容由 使用者自行定義。XML 有以下優點：簡單易讀、資料互通跨平台、具擴充性及容易被搜 尋(蔡利國，2006)。 XML 架構包含敘述 XML 資料的 XSD(XML Schema Defination)、控制 XML 顯示樣式的 XSL(eXtensible Stylesheet Language)，與聲明轉換規則的 XSLT(eXtensible Stylesheet Language Transformations)。XML 文件範例如圖 2-6 所示： 圖 2- 6 XML 資料範例(廖信彥，2007) 其中<?xml version=”1.0” encoding=”UTF-8”>是一份宣告，指定版本為 1.0 版，使用語言 為 UTF-8。XML 為巢狀語言，開始標籤如<供應商>必須配對結尾標籤</供應商>。 XML 描述資料表的資料紀錄，描述 XML 文件類型與結構的敘述為 XSD。下圖 2- 7 為 XSD 檔案，描述供應商資料架構。 圖 2- 7 XSD 資料範例(廖信彥，2007)

XSD 定義 XML 檔案標籤的結構描述，例如欄位名稱(供應商、聯絡人)，資料型態(nvarchar)， 資料長度(maxLength)等。使用結構描述，能保證匯入其他資料庫的 XML 檔案，與原本 檔案的資料定義架構一致。 XSL 負責展示 XML 文件的樣式部分。設定資料顯示的字體、顏色、大小，瀏覽器展示。 XSLT 譯為可延伸樣式表語言轉換，提供了轉換的基準，讓 XML 文件在轉檔過程提供參 考，例如轉檔至 HTML 文件、RTF 文件，讓其他應用程式讀取辨識。

3. JSON：JavaScript Object Notation，是輕量級資料交換語言，首見於 1999 年，在 JavaScript 標準提出的資料格式。JSON 與 XML 相比，在於 JSON 不需要巢狀的標籤包 覆資料，資料量小，讀取較 XML 快。

JSON 資料結構如下圖 2-8 所示，物件(object)以大括號『{}』包覆；相同的物件歸類為 同一陣列(array)，以中括號『[]』包覆；物件成員以『”欄位名稱(字串)”：” 屬性(值或字 串)”』紀錄，物件與物件間，以逗號『，』隔開。

圖 2- 8 JSON 資料(廖信彥，2007)

JSON 呼叫方式以 eval 函數將 JSON 資料傳換為物件，這樣的作法可能有風險，因為惡 意程式碼可寫在 JSON 檔案中，不經過評估直接解譯可能讓網站遭受攻擊，目前的處理 方式是利用 JSON 官網提供的轉譯器，將資料先進行安全性判斷，確定安全再繼續解譯 資料內容。

2.3 WebGIS

WebGIS 是透過網路讓使用者可以在網際網路(Internet)及內部網路(Intranet)中獲取、儲存、 整合、處理、分析及展示地理位置相關的資料，在客戶端(Client)使用而不需購買任何商業的 GIS 付費軟體(Painho et al, 2001)，WebGIS 概念如圖 2-9 所示：

圖 2- 9 WebGIS 架構示意圖(Painho et al, 2001) WebGIS 與傳統單機 GIS 相比，具有以下優點(翁維瓏，2001)： 1. 更廣泛的使用層面：使用者只要進入同一個 WebGIS 平台，背後的資料可能來自不 同的伺服器。分散式的概念讓地理資料的聚合及增加資料更為方便。 2. 平台獨立性：使用通用的 Web 瀏覽器，或在瀏覽器加上外掛，就能使用 GIS 資料， 能在本機或伺服器進行空間資料分析處理，或將處理完資料送回伺服器，實現網路資料 共享。 3. 降低系統成本：使用者的平台多屬瀏覽器，節省購置本機端 GIS 軟體成本。 4. 更簡單的操作：通常使用者不需要地理資訊分析功能，僅具備基本瀏覽功能的 WebGIS 就能滿足需求。 5. 平衡圖資計算負載：WebGIS 能利用網路資源，將基礎性、全面性如地理資訊處理 功能給伺服器執行，資料量較小的操作，如縮放平移給客戶端執行，如此可以將圖資計 算及網路流量做較合理的分配。

2.3.1 CGI(Common Gateway Interface)

CGI 是 1993 年由美國 NCSA(National Center for Supercomputing Applicaions)開發，能讓 使用者由瀏覽器存取放在伺服器上的資料。資料傳遞的過程如下：當使用者在瀏覽器端輸入 查詢資料後，瀏覽器會將查詢資料通過 CGI 傳給 Web 伺服器，Web 伺服器將參數傳給 CGI 處理程式，進 GIS 資料庫查詢，獲得結果後讓 CGI 處理程式再透過 Web 伺服器回傳給前端 瀏覽器。CGI 指令傳遞流程如圖 2-10 所示： 圖 2- 10 CGI 運作流程(黎翰林，1999) CGI 透過網際網路傳遞變數，使用者透過 HTML 表單遞交資料，如圖 2-11 所示： 圖 2- 11 CGI 呼叫程式執行功能 使用 CGI 的 WebGIS 具有以下優點(黎翰林，1999)： 1. CGI 程式僅能在伺服器端執行，執行失敗或發生錯誤，不會影響到使用者。 2. 利用伺服器處理 GIS 資料。 3. CGI 回傳的資料是影像及 HTML 資料，與使用者端平台無關。 2.3.2 ActiveX

ActiveX 是一種外掛程式(Plug-in)，在早期 WebGIS 將繪製圖層與資料處理的工作全部交 給伺服器，若連線人數增加或是不停請求圖形或資料，伺服器負擔大，開發插件技術，將一 部分運算功能交給使用者的電腦，讓使用者電腦處理功能例如地圖縮放平移，簡單的資料庫 查詢等工作，讓伺服器負責地理資訊運算或多資料表的複雜查詢功能，達成負載均衡目標。

ActiveX 技術將 WebGIS 中的各項功能拆解，變成一個個獨立的組件，透過程式開發組 合，組合成獨特的 WebGIS，ActiveX 可以利用多種語言開發如 VB，VC，VB.net 等，ActiveX 只支援微軟作業架構，要利用.NET Framework 開發的 WebGIS 才能跨平台。ActiveX 程式可 以控制使用者電腦的各個部分資源，完成客戶端運算，節約伺服器資源。但也因為 ActiveX 對個人電腦的控制權力太大，導致許多惡意軟體利用 ActiveX 漏洞侵入使用者電腦竊取資料， 另外不同數據需要下載不同的 ActiveX 元件解譯，使用不便。

2.3.3 Java Applet

客戶端安裝 Java 執行環境(JRE：Java Runtime Environment)就可以運作 Java Applet，Java Applet 有跨平台特性。呼叫 Applet 程式，當伺服器讀到<Applet>標籤，便能夠運作程式。Java Applet 能夠傳送 GIS 資料讓使用者可以獲得圖徵的資訊。Java Applet 的 WebGIS 系統有以下 優點及缺點(黎翰林，1999)。 優點： 1. 跨平台。 2. 網頁即應用程式，不需下載新版軟體。 3. 前端互動性技術，可讓網路程式設計分散為前/後端。 缺點：

1. Java Applet 跨平台是因為伺服器先將與系統機器無關的中間碼(P-Code)傳到前端使 用者的電腦，再即時編譯成機械碼(Machine Code)，但單機編譯機械碼的效率不高導致 傳輸與執行較慢。

2. 要先安裝 Java plug-in，屬於外掛程式。

3. Java Applet 在程式設計時有限制讀取前端瀏覽器資料等功能，造成程式設計限制， 某些功能無法開發。

2.3.4 Java Servlet

Java Applet 是在客戶端瀏覽器執行的程式。而 Java Servlet 是在伺服器執行，以伺服器進 行運算將結果回傳給客戶端。Java Servlet 用執行緒(Thread)使用者需求，一套運算能切割給 不同執行緒處理，減少處理時間。CGI 的執行方式則是每處理一個需求，都要將服務啟動， 運算，再回傳。若需求處理時間短，仍須等待程式的啟動。

Java Servelt 用來擴充 Web 伺服器功能，也可搭配 JSP(JavaServer Pages)技術建立動態網 頁。在 Java 程式碼中，呼叫 import javax.servlet.* 與 import javax.servlet.http.* ，讓 JSP 引用 Serlvet 功能，這兩個套件作用為處理客戶端的 HTTP 請求。Java Servlet 的生命週期如下圖 2-12 所示：

圖 2- 12 Java Servlet 的生命週期

2.3.5 OpenGIS

WebGIS 發展的趨勢也跟網際網路相似，資料的標準化更形重要，開放式地理資訊委員 會(Open Geospatial Consortium，OGC)已訂定相關標準供 GIS 開發商參考。目前 WebGIS 以標 準格式發展，以利空間資訊交換；WebGIS 在空間資訊處理可以利用 Web Service 方式計算， 以 REST 或 SOAP 協定傳輸地理資訊資料；結合混搭(Mashup)概念串組 API 開發彈性服務(On Demand Service)。

OSGeo(Open Source Geospatial Foundation)提供支持開放式標準的 GIS 應用，應用層面分 四類為：展示地理資訊圖資(Web Mapping)、單機 GIS 軟體(Desktop Software Application)、地 理資訊資料庫(Geospatial Libraries)及詮釋資料目錄(Metadata Catalog)。使用者及程式開發者

可免費地取用 OSGeo 的專案進行 GIS 應用，也開設論壇提報錯誤及開發經驗分享。

2.4 GDAS 與 GLS

GDAS 與 GLS(Geolinking Service)是 OGC 在 2004 年提出的規範，訂定空間資料與事件 內容的連結，以下分別對 GDAS 標準與 GLS 標準進行說明。 2.4.1 GDAS GDAS 是地理連接資料存取服務，事件發生的地點或區域有獨特且唯一的地理標識 (Geolinkid，GID)，將某地發生的事件或屬性寫入該地地理標識的資料表中。提取資料的方式 是搜尋該 GID，查詢發生的事件或屬性值(OGC, 2004)。由於 GID 具有唯一性，後續發生在 同一地點的事件可以 GID 作為索引繼續寫入資料庫，成為具有空間資訊的資料庫系統，以 GID 作為空間數據連接的基礎。例如交通大學光復校區，具有各棟大樓，以大樓為 GID，此 空間框架紀錄交通大學各棟大樓的經緯度位置(Geolocation)，事件的發布單位或活動地點可 以對應至各 GID，紀錄該 GID 內發生的事件詳情，屆時可以 GID 為查詢要素，分析該 GID 內發生的事件。例如工程二館在校內建物代號為 EB，以 EB 查詢最近發生的活動，可以查到 在 2010 年七月此地點正在舉行土木營活動，六月份有獎學金申請等活動。

GDAS 訂定請求資料的方式為 GetData 與 GetCapabilites 兩種操作方式，GetData 能透過 GID 取出資料庫中該 GID 的資料(框架定義為 Attribute)。GetCapabilites 方法則是查詢 GDAS 伺服器資訊如版本(Version)、網域(Domain)、GID 空間框架等。

空間連結資料(Geolinked Data)在 GDAS 架構分為三層，第一層為框架(Framework)、第二 層為資料集(Dataset)，第三層為屬性(Attribute)三類，一個空間資料可對應一個或多個框架， 一個框架可對應一個或多個資料集，一個資料集可對應一個或多個屬性。例如交通大學空間 連結資料(Geolinked Data)之下可分為交通大學空間位置框架(Framework)，紀錄交通大學各辦 公單位 GID，交通大學各單位職員及學生資料集(Dataset)記錄在各辦公單位下的職員與學生 名單(Attribute)。

屬性資料在 GDAS 規範定義四類：名目資料(Nominal)、級序資料(Ordinal)、測量值 (Measure)，次數(Count)。 查詢屬性資料(GetData)必須指定參數方可進行資料存取，以下列出所需參數： z 伺服器資料資訊：Service=GDAS(必要)、Request=GetData(必要)、Version=0.9.1(必 要)。 z 空 間 框 架 資 訊 ： FrameworkDomain( 必 要 ) 、 FrameworkName( 必 要 ) 、 FrameworkVersion(必要)。 z 資料集資訊：DatasetDomain(必要)、DatasetName(必要)。 z 屬性：Attribute(必要)，由逗號分隔要查詢的屬性。 z 空間標識：Geolinkids(選擇性)，由逗號分隔要查詢的 GID。 GDAS 是結合空間資訊的資料庫，GetData 回傳資料是 XML 檔案，利於後續應用，應用 面項主要有四： 1. 能將屬性資料以 HTML 寫在網頁中，例如資料查詢。 2. 將資料與 GLS 結合，將屬性資料結合地圖，產製主題圖表。例如交通大學各單位成 員之年齡分布圓餅圖。 3. 將資料轉為 csv 檔案，可在單機版本地理資訊系統應用。 4. 取出某部分資料，匯入其他 GDAS 或其他資料庫，將資料繼續處理應用。 只要在真實世界中能對應到地理空間的名稱，皆能編為 GID，空間連結資料也能以 GID 連結配合 GLS 進行後續應用。 2.4.2 GLS

由前節得知 GDAS 儲存了空間連結資料，不存入地物的圖徵(Geometry)，但透過 GID 能 對應到空間資料集(Geospatial Dataset)，例如新竹地區各鄉鎮市的人口統計資料，能透過鄉鎮 市的名稱(對應之 GID)進行地理位置對位，能產生各鄉鎮市的人口分佈圖徵資料。

GLS 是空間連結資料與空間資料集的連結服務，透過網路傳輸將取得的主題資料與後端 的空間資料以 GID 互相連結。操作的流程為：GLS 伺服器中，存有圖徵(Feature)資料，屬性 資料透過 GetData 方式取得後，以 GID 為索引，寫入屬性資料進入圖徵資料，則該圖徵資料 具有屬性，可利用屬性進行後續分析處理。GLS 處理資料的過程可見下圖 2-13 所示： 圖 2- 13 GLS 工作示意圖，呼叫 GDAS 與圖徵資料(OGC, 2004) 圖中客戶端應用(Client Application)通常是網路地圖服務(WMS)或網路圖徵服務(WFS)。 GLS 支援的操作有兩種型態： GeoCapabilities 與 GeoLink 兩種，GetCapabilites 可取得 GLS 版本與 GID 之空間框架。GeoLink 請求參數如下所列： z 伺服器資訊：Service=GLS(必要)、Request=GeoLink(必要)、Version=0.9.1(必要)。 z GDAS 請求：GDAS(必要)、GDASVersion(必要)。 z 框架資訊：FrameworkDomain(必要)、FramworkName(必要)、FrameworkHost(選擇 性)。 z 資料集資訊：DatasetDomain(必要)、DatasetName(必要)、Attribute(必要)、Geolinkids(選 擇性)。 z 圖層樣式描述：SLD(選擇性)。 z 連結保留天數：Cache(選擇性)。

GLS 的工作流程如下：發出 Geolink 請求(Request)參數由 GLS 分析後，透過 GetData 方 式向 GDAS 發出請求，收到 GDAS 的回應後由 GLS 處理，利用 GID 對應 GLS 的空間資料， 傳回 Geolink 回應(Response)。GLS 能與 WMS 或 WFS 伺服器連結，將由 GLS 製作完畢的「具 有屬性的空間資料」，發布成 WMS 或 WFS。

GLS 在 2004 年列為 OGC 討論文件(Discussion Document)，目前發布的版本為 0.9.1 版， 在 2009 年 GLS 列為「要求公眾建議」(Request for Comments)等級，有可能在 2010 年或 2011 年成為 OGC 標準(geoprocessing.info ,2010)。

第三章 混搭與地圖 API 探討

3.1 混搭與地圖混搭

混搭(Mashup)一詞源自將不同風格的音樂混合，產生新音樂的方式。在網際網路上，混 搭整合網路上多個資料來源或功能，創造新服務的網路應用程式。應用程式使用其他網站提 供的功能是混搭。利用網址(HTML 的 href 語法)連結的功能，例如使用別的網站的圖片，則 不是混搭。 混搭的建置方式可以是網站或應用程式，來源多數由第三方提供，依使用者需求建置混 搭程式。混搭的建置過程應該有以下四階段：(Boulos et al., 2008) 1. 資料收集：混搭程式的資料來自不同網站，獲得資料方式為複製或連結該網站資料， 可以用人力或利用程式將網頁資料蒐集，開發好的搜尋網頁程式，例如 Dapper，能掃描 網頁內容，將結果發布為 RSS 或嵌入碼。 2. 資料連接：將收到的資料處理，或整合其他資料，例如 Yahoo!Pipes 可以接受 RSS 及網址，取出內容，將內容傳遞到運算器做排序或地理對位等運算，可發布結果。 3. 資料展示：將產出的結果發布為不同格式，以便其他程式讀取介接，例如將 RSS 或 Atom 加入地理對位，以 KML 發布，可在 Google map 與 Google Earth 展示。

4. 資料分享：將成果分享在網路上，讓其他使用者取用或學習。 混搭的建置方式可分為伺服器端混搭(Server-side Mashup)與用戶端混搭(Client-side Mashup)兩種建置方式(Ort et al.,2007)。 3.1.1 伺服器端混搭 在伺服器端混搭，所有從用戶端發出的請求會經過伺服器端的代理模組(proxy class)，負 責處理使用者請求並與其他網站進行互動，整合這些請求的服務與內容，轉換為要展示的格 式給使用者，混搭的過程在伺服器端進行，如圖 3-1 所示。

圖 3- 1 伺服器端混搭 流程說明如下： 1. 使用者發出事件，觸發 JavaScript 函式。 2. 用戶端向本機 Web 伺服器發出請求。 3. Web 伺服器收到用戶端請求，呼叫一個或多個代理模組連線到第三方網站。 4. 由代理模組連線到第三方網站，並請求服務。 5. 第三方網站處理需求後回傳至代理伺服器，通常是利用 HTTP GET 與 HTTP POST 為媒介傳送資料。 6. 代理模組接收回傳資料，處理成用戶端需求格式；代理模組亦能暫存第三方網站的 回傳資料，進行下一步用戶端請求處理。 7. Web 伺服器回傳資料給用戶端。 8. 更新 Web 伺服器資料，透過回收(callback)函式傳送到使用者瀏覽器。 伺服器端混搭的例子，例如在自己的網頁嵌入一個 Dapper 或 Yahoo!Pipes 的視窗，而 Dapper 與 Yahoo!Pipes 是混搭連結程式，資訊會先經過 Dapper 與 Yahoo!Pipes 處理，暫存處 理成果，再轉送到使用者視窗，故代理模組即 Dapper 或 Yahoo!Pipes。

3.1.2 用戶端混搭 用戶端混搭少了代理模組的輔助，用戶端直接向第三方網站請求所需要的服務或內容， 下圖 3-2 為客戶端混搭圖： 圖 3- 2 用戶端混搭 流程說明如下： 1. 使用者透過瀏覽器發送請求。 2. 從 Web 伺服器載入網頁，伺服器會需要一組包含第三方網站的 JavaScript 函式庫， 例如要呼叫 Google Map，必須先在伺服器程式碼呼叫 Google Map 的 JavaScript。 3. 使用者觸發事件，這些動作可能會觸發 JavaScript 函式，產生<Script>動作。 4. 需求事件透過<Script>傳送到第三方網站，並送出 HTTP 請求。

5. 第三方網站處理請求與回傳資料。

6. 用戶端函式庫獲得回應，將資料更新到使用者瀏覽器中。

用戶端混搭的範例為網站內使用 Google Map 地圖。使用者拖拉或縮放地圖，傳送需求 給 Google Map，由 Google Map 處理以後直接回傳給使用者，沒有透過 Web 伺服器。

3.2 API(Application Program Interface)

由於軟體設計日漸複雜，規劃軟體建構方式變得十分重要，建議將軟體功能分割成各個 小型程式，再進行程式整合。這些被分割的小型程式，以應用程式介面(API)的方式被呼叫。 在程式設計中，應用程式介面劃分各個程式的權責，設計良好的應用程式介面可以降低各個 程式間依賴程度，提高系統的維護性與擴充性。

API 是一種複雜的函數和副程式，可讓程式設計人員引用完成工作，如 Google Maps api 可以顯示地圖、疊合各種圖層，與調整展示樣式等，ArcGIS API for JavaScript 除了能呼叫地 圖外，還可以支援由 ArcGIS Server 開發的地理資訊處理服務(Geoprocessing Service)。

混搭利用 API 製作，程式設計者利用 API 呼叫資料或服務，API 有助應用程式資料交換， 開發新應用程式(Murugesan, 2007)。ProgrammableWeb 這個網站提供了 API 資料與混搭連結， 使用者上線提供目前可用的 API，將其歸類，分類項目可見下圖 3-3(a)；程式開發人員也可 利用該平台展示以何種 API 開發的網頁應用程式。在 2010 年六月，該網頁統計目前全球共 有 2016 種 API 與 4864 個混搭網頁程式。

如圖 3-3(b)所示，該混搭收集世界各旅館資料，使用者設定某個點及搜尋半徑後，可搜 尋該地區某範圍內的旅館及價格。

3.3 網路地圖 API(Web Map API)比較

本研究比較三大類以 Ajax 技術開發的地圖 API，分別是入口網站開發的地圖 API，商業 軟體 ESRI 開發的地圖 API，以及 OpenSource 的 OpenLayers API。以下就各地圖支援的底圖 圖層、支援疊圖圖層、控制項、附加服務以表格說明，參見以下各節：

3.3.1 入口網站提供的 Map API

1. Bing Maps Ajax API(V6.3 ,June 2010)：微軟開發的地圖入口網頁，前身為 Live Search Maps，Bing Maps Ajax API 與微軟其他系列 API 差別主要在於 Ajax API 提供了 3D 地圖 控制，切換到 3D 模式能觀看地形與 3D 建築物，亦可以 3DVIA Shape for Maps 繪製 3D 建築物。新功能如街景(StreetSide)、混搭小工具(Widget)、Photosynth 功能還未開放使用。 開發網路應用程式需要申請 Bing Maps Key。衛星照片如圖 3-4，在交通大學光復校區有 雲層遮蔽。

2. Google Maps API(V3)：Google Maps 在 2009 年五月推出了第三版本的 API，主要差 異在於(a)命名架構改變，命名空間(name space)由 G 改為 google.map。(b)事件處理採取 MVC(Model-View-Control)架構。(c)加強 Android 和 iPhone 手持裝置支援。(d)Geocoding 效率改善。(e)不需申請 Google Maps API Key。(Google Maps JavaScript API V3, 2010)。 Google Maps API V3 對於程式開發人員是比較新的資訊，由於命名空間與控制事件的方 式改變，程式碼需要大幅度的修改。第二版與第三版 API 功能無差異，同樣可以使用地 理編碼、高程、導航等服務。以下圖 3-5 是交通大學光復校區之衛星照片。無雲層遮蔽， 比例清晰，但年代稍舊，無交映樓與田家炳光電大樓。

3. Yahoo!Maps(V3.8)與 Yahoo!奇摩地圖

Yahoo!Maps 與 Yahoo!奇摩地圖在台灣地區有不同向量圖資，Yahoo!Maps 可見圖 3-6(a)， Yahoo!地圖可見圖 3-6(b)，在圖台具有 POI 資訊。取用 Yahoo! Maps API 進行混搭需要申 請一組 API Key，如果要使用台灣地區的底圖則選用固定的 API Key。兩者在新竹衛星 底圖解析度都不高，可見圖 3-7，不利於展現交通大學底圖影像參考。

圖 3- 6(a) Yahoo!Maps (b) Yahoo!地圖在交通大學光復校區向量圖

圖 3- 7 Yahoo!Maps/地圖在新竹地區衛星影像

表 3- 1 入口網站提供的 Web Map API 比較

功能 Bing Maps Google Maps Yahoo!奇摩地圖 /Maps 註冊 Key _需要 V3 不需要 V2 需要 需要 提供底圖 _{向量圖資(英文)} 衛星影像 向量圖資 衛星影像 地形圖層 向量圖資(中/英) 衛星影像 特殊圖層 3D(需安裝插件) Bird’s eye Google Earth(需安裝插件) 街景圖層 無 控制項 圖層切換器 縮放平移 鷹眼圖 比例尺 圖層切換器 縮放平移 鷹眼圖 比例尺 圖層切換器 縮放平移 比例尺 建立圖徵 _點 線 面 點/可拖曳點 線/大圓線 面 具圖徵工具繪製圖徵/測量 點 線 影像套疊 _{影像(Tiled)} 影像(整幅) 影像(Tiled) 無 向量套疊 GeoRSS VECollection KML GeoRSS Glayer KML GeoRSS(點、線) 地 理 編 碼 (GeoCode) 地理編碼 反向查址 地理編碼 反向查址 地理編碼 反向查址* * :屬 Web Service， 不在 Map API class 內

限制 [教育與非營利組織] (a)24 小時內地理編 碼只能做 50,000 個 (b) 一 次 最 高 提 取 250 個 POI (c)real-time 導航 (d)禁用 bird’s eye (e)禁止整合其他地 圖平台資訊在 Bing Maps (a)KML 單 檔 不 大 於 10mb，KMZ 單檔不大於 3mb (b)24 小 時 內 地 理 編 碼 15,000 個 (c)服務/程式不得收費 (a)網站每日連線數上 限 50,000 次 (b)24 小時內地理編 碼只能做 5,000 次

3.3.2 商用軟體 ESRI 提供的 Map API－ArcGIS API for JavaScript

ArcGIS API for JavaScript(V 1.6)是 ESRI 公司開發的地圖 API，此 API 是利用 dojo JavaScript 語言為基礎進行開發，能執行控制項設定、呼叫圖層、呼叫服務、繪製圖徵、設定 版面樣式等功能，並且對 Google Maps 與 Bing Maps 兩地圖 API 開發擴增 (Extensions)。

ESRI 在 ArcGIS Server9.3 版本將服務加入 REST 協定，服務開發者使用 ArcGIS Ajax for JavaScript 可利用 REST 協定能執行串接圖層、地理資訊處理服務(Geoprocessing Service)， ESRI 官方提供相當多的地圖與服務，可瀏覽服務說明並進行引用。以下對此 API 與其擴增 版本功能進行說明： 1. 地圖控制項(Map)：定義地圖元素。 2. 圖層控制項(Layer)：疊合網格圖層與切細(Tiled)網格圖層。 3. 幾何控制項(Geometry)：空間幾何項目，包括圖層範圍(extent)，坐標系。定義圖徵 點、線、面。 4. 工具項(Toolbars)：繪製點、線、面工具，瀏覽工具。 5. 任務控制項(Task)：選擇服務項目，設定輸入變項、輸出變項，及模型參數。 微軟 Bing Maps 提供了控制項給 ArcGIS JavaScript API，使用者能利用控制項呼叫微軟的 圖層、地理編碼服務。

ArcGIS Server 9.3 版本加入 REST 通訊協定，利用 ArcGIS Server 製作的服務，發布後便 可以利用 REST 協定引用，如下圖 3-8，使用者連結服務的網址可看到服務的描述與輸入輸 出的變數。

圖 3- 8 ArcGIS Server 提供的地理資訊處理服務(Geoprocessing Service)

ArcGIS JavaScript API 另有兩個延伸版本，一為可以配合 Google Maps 的；另一為配合 Bing Maps 開發的套件，除了可以呼叫原本地圖 API 所提供的底圖之外，另外還能支援以 REST 協定開發的服務。

利用 ArcGIS API JavaScript 可與 ArcGIS Server 配合開發混搭網頁程式，圖 3-9 為一開發 範例，目的為計算台灣地區等溫線圖，疊合於圖台。利用 ArcGIS Desktop 的 Model Builder， 輸入項為台灣地區各氣象站氣溫 shp 檔案，經 IDW 法內插氣溫網格圖後，以台灣 shp 檔案為 出圖參照進行裁切，將成果網格圖回傳至圖台。此範例先利用事件聆聽器(滑鼠點選地圖)定 義範圍後，以 REST 協定呼叫 Geoprocessing Service 開始進行繪製氣溫圖與成圖裁切工作， 最後利用疊合圖層方式將氣溫圖套疊於圖台。

圖 3- 9 以 ArcGIS API for JavaScipt 開發的台灣等溫面圖

ArcGIS JavaScript API 若結合 ArcGIS Server 提供的圖資與地理資訊處理服務開發客製的 圖資與地理資訊應用程式。但 ArcGIS Server 是專業地理資訊系統軟體需付費，而官方網站提 供之地圖與服務多限於美國地區，對台灣使用者可能無法感受到這些服務帶來的便利性。

3.3.3 自由軟體提供的 Map API－OpenLayers

OpenLayers(V 2.9.1)是 MetaCarta 公司開發，用於 WebGIS 客戶端的 JavaScript 函式庫， 是 OSGeo 的成員，引用 OpenLayers API 不需要申請 Key，但串接商業入口網站底圖則需要 該底圖的 API Key，例如疊合 Google Maps 圖資需要申請其 API Key。支援 OGC 規範服務如 WMS、WFS，GML 等圖資發布標準外，亦能與入口網站地圖 API 疊合，如 Bing Maps，Google Maps 等。該函式庫類別如下說明： 1. 控制項：圖層控制器、縮放平移、鷹眼圖、比例尺。 2. 圖 徵 控 制 ( 縮 放 平 移 、 旋 轉 ) ， 測 量 ( 距 離 、 面 積 ) 。 獲 得 WMS 圖 徵 資 訊 (WMSGetFeatureInfo)、選取 WFS 圖徵(GetFeature)。 3. 建立圖徵：點/可拖曳點、線/大圓線，面。有繪製圖徵工具繪製圖徵/測量。 4. 套疊影像圖層：Image、TileCache、WMS、WMTS。 5. 套疊向量圖層：GML、GeoJSON、GeoRSS、KML、Text(點)、WFS。

6. 擴充連接圖層：ArcGIS93Rest、Bing Maps、Google Map、KaMap、MapGuide、 MapServer、OSM、WorldWind、Yahoo!Maps，Zoomify。

OpenLayers 由於控制功能豐富、圖層種類兼容 OGC 標準與商業圖資，使 OpenLayers 適 合作為圖資展示平台，若需引用入口網站底圖(如 Google Maps)須注意坐標系定義問題，由於 Google Map 採取 EPSG：900913 坐標系，當圖資在匯入圖資 Server 時就要準備對圖資進行坐 標轉換，以下圖 3-10 是一個利用 OpenLayers 當作圖層展示平台的 WebGIS，將台灣 SRTM 高 程圖(坐標系：EPSG 4326)以分層設色方式疊圖於 Google Maps 上，圖資在 GeoServer 先經過 坐標轉換才能與 Google Maps 做準確的套疊。

圖 3- 10 以 OpenLayers 展示台灣地區 SRTM 高程圖

OpenLayers 提供了 proj4 函式轉換參數，右下角之坐標值原本為 ESPG：900913 坐標系， 經過轉換可調整為 WGS84 坐標值，提供坐標參考資訊。 3.3.4 小結 由前述 API 比較得知，入口網站 API 優勢在於更新基本圖資速度較快速，基礎教學資源 因使用者眾多而豐富，有地理服務如導航與高程可取用，例如導航與搜尋功能等；缺點是圖 資擁有權在入口網站，無法保證目前使用背景圖層永續性及可用性。商業軟體 API 優勢是能 夠以 REST 協定連結自有圖層與地理資訊處理功能，能建立專屬的圖層或服務；缺點是免費 的圖層或服務多屬美洲地區，在台灣地區需要配合 ArcGIS Server 為付費軟體，限制使用者進 入門檻。OpenLayers 的優點在於圖層可搭配 OGC 協定與商業入口網站，增加圖層可用性； 缺點是開發資源相較於入口網站較少，網路服務速度受限於提供者伺服器。有關三類地圖 API 比較整理如下表 3-2。綜合以上比較，本研究以圖資連結效率與未來擴充地理資訊功能為主 要考量，選擇入口網站地圖 API 而不選取自由軟體地圖 API，以交通大學光復校區衛星影像 品質較好的 Google Maps API 進行後續研究。

表 3- 2 地圖 API 比較 API 名稱 疊合向量 資料 疊合影像 資料 地理編碼 圖徵 其他資源 入口網站 Google Maps API GeoRSS、 KML 單張/金字塔 地理編碼/ 反向編碼 點 線 面 圖徵繪製工具 Google Earth 街景 導航 高程 商業軟體 ESRI ArcGIS API forJavaScript 利用 Geomertry() 呼叫 單張/金字塔 Geoprocess-ing Service 點 線 面 圖徵繪製工具 Geoprocess- ing Service 自由軟體 OpenLayers GML、 GeoJSON、 GeoRSS、 KML、 Text(點)、 WFS Image、 TileCache、 WMS、 WMTS 無 點 線 面 圖徵繪製工具 無

混搭地圖 API 可以利用客戶端混搭(Client-side mashup)，此類程式直接與被呼叫的伺服 器進行互動(例如底圖是 Google Maps)，開發人員甚至不需要將程式碼放在自己的伺服器也可 以運作，開發簡單，具有基本的 GIS 功能如量距。以混搭方式實現 WebGIS，重點在於 JavaScript 支援性與樣式控制(DOM 與 CSS)差異，建議使用通用函式庫開發混搭程式，以免各瀏覽器支 援與閱讀的狀態不同。

若混搭牽涉資料庫資料傳遞，則建議以動態網頁語言如 ASP.net、JSP，PHP 等語言開發 混搭，將程式碼寫在動態程式碼內，避免程式碼外洩。

3.4 地圖 API 混搭開發的 WebGIS 與套裝 WebGIS 比較

利用地圖 API 混搭開發的 WebGIS(以下簡稱混搭 WebGIS)與套裝 WebGIS 操作方式大約 相同，其中不同處可歸類為以下三點：

1. 圖資來源與圖資處理：混搭 WebGIS 以 Ajax 非同步傳輸技術傳遞圖資，圖資在各個 解析度層級先經過影像金字塔處理將圖層分割以增加傳輸效率。而套裝 WebGIS 圖資組 成可以來自符合 OGC 標準的格式如 WMS(Web Map Service)，WFS(Web Feature Service)， 或串接圖資伺服器。若伺服器未能提供金字塔分割處理影像，則必須以 On-the-fly 方式 重新計算影像在展現於圖台，在圖層呈現上就無法享受到非同步傳輸的效率。目前 OGC 推動 WMTS(Web Map Tiling Standard)，將圖資以金字塔方式分割後發布圖資。未來可期 待符合開放標準的 WMTS，獲得更好的瀏覽體驗。

圖資來源在混搭 WebGIS 方面，各個 Web Map API 廠商都有自己的底圖，使用者可依系 統規畫需求串接所需要的底圖。比較特別的是 OpenLayers API 屬於 OpenSource 軟體， 沒有自己的圖資，但可以串接各種圖層，從入口網站的 Google Map 底圖，OGC 標準的 各種圖資，也能夠串接由使用者自願提供資料的 OSM 底圖，將使用者提供的資料再運 用，達成 Web2.0 的共享理念。

2. 建置方式差異：混搭 WebGIS 利用 Web Map API，廠商通常會提供不同底圖與控制 項介面(User Interface)讓開發者選用，控制的功能僅縮放平移與套疊基本功能，但強調效 能，使用者能流暢的瀏覽地圖。套裝 WebGIS 則可以帶有一部分分析功能，例如計算緩 衝區(Buffer Zone)或內插資料等，效能則依伺服器處理能力而異。

3. 功能差異：混搭 WebGIS 能結合各種不同的 API 開發服務，例如 Google Maps 本身 結合搜尋、地理定址、導航、Google Earth Plug-in 等功能，相較於套裝 WebGIS 服務較 多變化。而套裝 WebGIS 的強項則在於專業的地理資訊分析處理功能，速度不是最優先 考量。

可以考量衛星解析度較佳、瀏覽速度快，開發資源相對豐富的 Google Maps API 第二版，作 為本系統開發。

3.5 Google Maps API V2 版本建置方式

本研究利用 V2 版本 API，在系統網頁嵌入 Google 地圖。開發的方式為利用該 API 呼叫 校園衛星底圖，建立地圖控制項，進行疊圖等工作。

當使用者透過應用程式網頁(Application Page)查詢某個特定 POI 資訊時，動態網頁(本研 究使用 ASP..net)與資料庫伺服器互動，查詢資料庫的 POI 資料透過 Google Maps API 呈現給 用戶端使用者。

Google Maps API 除地圖物件外，還有其他部分，如下說明：

1. Map Event：在地圖上進行滑鼠點選或鍵盤操作等動作，在 JavaScript 是以事件(event) 驅動，當 JavaScript 的事件監聽器(Event Listener)接收到觸發訊息後，便會執行相應動作。 2. Map Controls：Google Maps API 有不同造型及功能的使用者介面(UI)物件，與地圖 進行互動。例如控制地圖選項與縮放比例尺操縱等功能。

3. Map Overlays：疊圖選項，Google Maps API 允許疊合不同類型資料，例如點 GMarker、 線 GPolyline、面 GPolygon、Google 服務圖層 GLayer，與影像金字塔圖層 GTilelayer 等。 4. Map Services：例如地理定址(GeoCoding API)、導航(Directions API)、高程(Elevation API)，尋點(Places API)等服務。

表 3- 3 本研究使用 Google Maps API 函式 函示使用功能 Google Maps API 呼叫方法 建立地圖物件 GMap2() 設定地圖格式 (衛星地圖) setMapType(G_SATALLITE_MAP) 設定地圖中心 setCenter() 建立經緯度元素 GLatLng() 建立控制項 addControl() 建立小控制圖示 addContol(GSmallZoomControl()) 建立比例尺 addControl(GScaleControl()) 建立點 GMarker() 開啟點位說明資訊 openInfoWidowHtml() 設定點樣式 GIcon.Image 建立 KML 元素 GGeoXml() 進行疊圖 addOverlay() 清除疊圖 removeOverlay() 清除所有疊圖 clearOverlays()

本研究以 Google Maps API 呈現的結果如下圖 3-11 所示：

圖 3- 11(a) 交大全部單位地標(左) (b) 交大地標(右上) (c) 交大訊息地圖(右下) 圖 3-11 介紹本系統利用 Google Maps API 開發的各種顯示圖層功能，圖(a)為 KML 疊圖 功能，圖(b)為定位校園建物功能，圖(c)為檢視校園新消息發布功能。後續研究則以此 API 混搭建置地理資訊圖台。

第四章 交通大學光復校區事件導向地理資訊系統建置

4.1 事件導向地理資訊系統

地理資訊系統能有效地傳達圖形資料，發展潮流轉變為網路化，只須連線到網路就能瀏 覽地圖。信息資料能結合空間標籤，成為空間連接資料(Geolinked Data)。若能將學校發布的 事件以空間連接資料發布，使用者可在圖台上尋找資訊，加強校園內事件傳遞能力，整合校 園資訊於 WebGIS 平台，亦能顯示事件與事件在地理空間的分布位置。 事件導向地理資訊系統的主體來自於事件(Event)，在交通大學光復校區之中，有各種型 態的事件發生，例如課程、活動、演講、行政公告等事件，這些事件的發生在時空面向上， 是可以被紀錄的。 事件發生有三個基本要素(Ott, 2001)：事件本體(What)、事件發生時間(When)、事件發生 地點(Where)，如圖 4-1 所示 圖 4- 1 時間、空間、屬性三者關係(Ott, 2001) 校園事件導向系統，以事件、空間，時間三者要素互動來記錄事件發生內容，以事件為 主體，分析事件在空間、時間的相位關係。並且以設定某個固定空間、時間的方式，來分析 事件的相互關聯性。

4.2 交通大學事件導向地理資訊系統

交通大學內有三個主要的訊息發布系統，第一個是教務處課務組提供的課程系統，第二 個是聯合服務中心的校園公告系統，第三個是公共事務委員會的校園新聞發布系統。這些系

統能提供兩個種類事件，一類是不具有活動地點的新聞，另一類是具有活動地點的實地事件。 這兩類訊息可以提供文字資料給使用者，但不能夠在圖像介面傳達發生地點，若以 WebGIS 的輔助在圖面上回傳資料，能了解事件內容，也能知道發布地點。故校園事件導向地理資訊 系統的目的主要有三： 1. 傳達校園空間資訊，建立校園圖徵資訊。 2. 以時間空間面向對事件進行查詢。 3. .建立校園事件發布頁面與查閱頁面。 由以上三點目的，將現有校園事件資料以混搭方式建立於網頁平台，對建置成果進行評 估，提出建議，讓校園事件導向地理資訊系統能成為資訊整合與後續地理資訊應用的參考架 構。

4.3 交通大學校園事件資料庫

1. 教務處課務組 99 學年度上學期課程資料：提供課程時間表、課程名稱表與科目表。 此三表藉由共通欄位將資料整合，資料表檢視可見下圖 4-2 所示： 圖 4- 2 校園課程資料檢視表 建立此檢視表可以查詢[上課星期]、[上課時間]、[教室]、[永久課號]、[課程名稱]等五項 屬性。授課教師資料以學校教職員工代碼登記，而教師中文姓名列於學校教職員職工表，

屬私人資訊無法取得，故校內學期課程查詢以此五項屬性作後續引用處理。 2. 聯合服務中心資料：交通大學聯合服務中心，建立平台讓各單位能發送事件公告訊 息於「校園公告系統」，建立六大類別公告事件，演講、行政、學術、活動、招生、徵 才，各類別建立 RSS 發送機制，使用者可訂閱其中某類別的公告資訊。 由聯合中心取得的資料，取出[公告單位]、[活動大綱]、[活動內文]、[事件開始日]、[事 件結束日]五項欄位供後續資料處理應用。 聯合服務中心提供六類別 RSS 訂閱服務資訊，屬於公開資訊，將資訊以 XML 格式寫入 資料庫可利用 Yahoo!Pipes 與 Microsoft Office Access 2007 進行資料處理與匯入資料庫工 作，工作流程可參閱附錄二。 3. 交通大學公共事務委員會資料：公共事務委員會為另一發布校園訊息平台，收集校 內新聞，將校內新聞整理，發布為電子信件至訂閱者信箱。 公共事務委員會另有活動發布平台，若校內有活動要公布，上網填具事件內容經審核後 可進行發布。由於發布單位較少，內容多數以新聞為主，缺少事件的活動內容與活動地 點，在校園事件導向地理資訊系統展現方式以 Dapper 掃描公共事務委員會網頁，將最新 消息以混搭方式嵌入於系統中，可參見下圖 4-3。製作嵌入式頁面流程請參閱附錄一。 圖 4- 3 以 Dapper 掃描交通大學公共事務委員會發布新聞

4.4 建置交通大學校內地標資料表與面圖徵資料

利用 Google Earth 建立校內各棟大樓與地標之坐標，檔案為 KML，坐標系採取 WGS84 經緯度，建置結果如下圖 4-4(a)所示，共計 88 個地標點。校內圖徵資料為 TWD97 二度分帶 坐標地形圖 shp 檔案，轉換坐標系為 WGS84 經緯度，轉檔為 KML，由 Google Earth 編輯圖 徵屬性，如下圖 4-4(b)所示。 圖 4- 4(a) 校內地標點位資料 (b) 校內建物面圖徵資料 將地標點位坐標輸入資料庫，建立交通大學光復校區點位資料表(NCTU_Locations)，各 資料表欄位(Column)以中括號[]表示，紀錄[經度]、[緯度]、[地標分類]，[地標名稱]四個欄位， 利用此資料表建立校內空間參照框架。 得到校內地標能進行校園內各棟大樓的定位，學校內各單位定位則參考「國立交通大學 網路電話簿系統」，將校內一二級單位計 183 個定位至各棟大樓內，作為發布單位之空間參照， 校內單位定位的資料表命名為 Institude_LatLon，例如土木工程學系在工程二館，可見下圖 4-5。

圖 4- 5 利用交通大學網路電話簿系統建立校內一二級單位空間對照

校內一二級單位可對應於校園各棟建物，故利用校園空間資料表能定位校園一二級單位， 以及校內各地標。

4.5 系統設計與建置

4.5.1 系統規格與架構

本系統作業平台為 Widows XP SP3，使用資料庫伺服器為 SQL Server 2008 Express，網 頁伺服器為 IIS 5.1 版，開發語言為 ASP.net 與 C#，混搭地圖 API 採用 Google Maps JavaScript API V2，系統為三層式架構，可見下圖 4-6

本系統設計運作流程圖如下 4-7 所示。 圖 4- 7 交通大學校園事件導向地理資訊系統運作流程圖 4.5.2 設計系統資料表與空間對應關係 本系統設計事件查詢由時間、空間，事件三件要素設計交互查詢。將以上校園訊息寫入 資料庫 NCTUEventGIS，將校園課程、校內公告與校園消息之資料與空間框架對應，設計三 個資料表 LocationFindCourse、Location_find_event 與 NowEvent_Message 做後續處理應用， 以上三個資料表建置方式如下： 1. LocationFindCourse：由地點與時間查詢課程，自教務處課務組擷取課程資料庫的 CourseTime、CourseTable，Subject 資料表，課程資料以[永久課號]為索引鍵，帶出其他 課程資訊。空間資料以[上課教室]對應至各棟大樓，如圖 4-8 所示。 圖 4- 8 LocationFindCourse 資料表對應關聯圖 2. Location_find_event：由地點與時間查詢事件，利用交通大學聯合服務中心發布之資 料庫，選擇[活動內文]、[活動日期]等欄位，空間對應以[發布單位]對應至各棟大樓，如 圖 4-9 所示。

圖 4- 9 Location_find_event 資料表對應關聯圖 3. NowEvent_Message：校園消息表，使用者可利用公開的地圖留言頁面將校園有關的 訊息寫入資料庫，再利用資料庫讀取與混搭方式將訊息寫回圖台。 4.5.3 系統查詢設計與建置 由以上三資料表製作三種查詢，設計方式說明如下： 1. 指定日期與地點查詢課程：利用 LocationFindCourse，以[星期幾]為第一參數，[校園 大樓]為第二參數，選出[課程名稱]、[上課時間]、[上課教室]，[永久課號]四個欄位。在 地圖上顯示。例如 99 年度上學期的課程資料地點在工程二館，時間在星期三，查詢成 果可見下圖 4-10。 圖 4- 10 以[星期幾]與[校園大樓]查詢課程