第六章 結論與未來展望
程式碼 11 利用 Ajax 執行跨網站服務要求
Ajax 在背後以 POST 方式進行 XMLHttpRequest，data 為網址引入參數，並 指定利用processData()函式作回呼（callback），dataType 為服務回傳格式，在這 裡指定以jsonp 的方式回覆。取得的資訊格式如下：
變數名稱 敘述
PartitionKey 系統辨識碼
43
RowKey 資料庫辨識碼
Timestamp 時間戳記
entityid 資料辨識碼
stitle 標題名稱
xpostdate 資料發佈時間
xbody 資料內容
xcreateddate 資料生成時間
xaddress 住址
gtag_longitude 經度座標
gtag_latitude 緯度座標
表 9 公開資料平台介接欄位說明
44
第四章 系統實現
本章第一節簡述系統建置環境與使用情境，第二節展示手機平台及平板使用 的介面呈現，並簡述其流程跟說明。
第一節 系統建置環境與使用情境
本系統建置環境分為兩個部分，其中網頁伺服器部分環境如下：
Java 執行環境（JRE）：版本 1.6.0
Apache Tomcat：版本 6.0.0
有關node.js 的環境如下：
node.js 服務：版本 v0.6.18
npm 擴充套件管理：版本 1.1.21
socket.io 套件：版本 0.9.6
45
本研究利用HTML5 及 JavaScript，實作一個行動平台互通的使用者介面，可 在具有支援HTML5 標準瀏覽器的任何裝置上執行，並提供使用者進行地圖介面 的導覽與查詢。
圖 12 系統使用情境案例圖
在開發環境上，使用的是Mac OS X 作業系統，搭配 Eclipse 的開發環境，進 行JavaScript 以及 HTML5 的程式碼撰寫及偵錯，其中的自動排版功能以及程式 碼自動完成功能可以加速協助程式開發的進行。並利用Google Chrome 瀏覽器觀 察程式碼的執行過程及錯誤，進行細節的偵錯及修改。
46
圖 13 Eclipse 開發環境介面
第二節 介面呈現
本系統開發期間，主要藉由手機介面進行測試，因手機的硬體資源比電腦平 台薄弱，在測試上反而比較容易判斷介面的盲點，以及效能上的問題，加上手機 裝置的定位功能齊全，也正契合本研究的研究目標。
47
圖 14 使用者主要入口頁面
主介面包含兩個主要功能的按鈕，一個角色選擇的下拉式選單，以及暱稱設 定。兩個主要功能分別為Google 地圖查詢以及 WebSocket 即時對話功能。在暱 稱的部分，使用了localStorage 來存放本機的暱稱資訊，預設名稱為 guest，而當 進行設定之後，日後進入畫面就會以之前設定的暱稱預設顯示。
在主畫面時並不會進行Web Socket 的連線動作，分別實作在地圖服務以及即 時對話兩個系統當中。
48
圖 15 使用者角色選擇
使用者在主頁面時，即可自行選擇使用者的角色設定，在服務內容部分也會 隨著角色的不同，展示不同的結果。
角色的選擇如下：
居民：以居住在台北市的居民為主，提供生活化的資訊。
觀光客：以外地前往台北市的族群為主，顯示的是即時方便的資訊。
運動員：以在台北市區域內活動的族群為主，顯示運動設施等資訊。
49
圖 16 使用者在輸入框中輸入訊息
進入多方談話介面，如同一般的聊天介面，使用者透過對話框輸入訊息，將 訊息送出，這裡使用的是Web Socket 架設的多方談話服務，當使用者在輸入框中 輸入欲送出的訊息，送出後便會透過Web Socket 立即送交服務處理。
50
圖 17 送出訊息並即時更新畫面
當服務收到訊息後，會立刻將目前存放於服務中的歷史訊息，全部回傳至介 面上，依照新＞舊的順序排列，訊息顯示包含發話人暱稱，訊息內容，以及發送 日期時間等等。
介面背後，利用一個Timer 不斷的檢查伺服器上的訊息，若是訊息內容有變 動，便會立刻將資料更新至畫面上。
51
圖 18 使用者進行定位及圖面顯示
當進入地圖介面時，首先會使用到的是Geolocation 功能，此時瀏覽器會跳出 視窗詢問使用者是否願意提供裝置的定位資訊，以便進行圖面上的定位，這是 Geolocation 標準當中一個隱私權的設計，以提醒的方式告知使用者，避免在同意 提供定位資訊後，造成不必要的誤會。
在利用裝置偵測目前的經緯度資訊後，會將自己的定位座標放置在地圖畫面 上，以小貓的圖示呈現，進入地圖介面後，背景的Timer 便會開始運作，不斷的 將自己的座標位置傳送至Web Socket 服務。
左下角的定位功能，能夠將畫面快速的定位至自己的位置，以便觀看周邊的 點位資訊。
52
圖 19 拖放定位圖示以進行街景呈現
而在Google 地圖介面中，除了可使用地圖的兩指縮放（部分裝置無法完全支 援，因蘋果擁有相關的觸控專利技術），還提供了一個街景導覽的功能，使用者 可使用地圖左上的衣夾人，將之拖曳至街道上，此時街道會呈現藍色的描繪線，
代表該路段已經支援Google 街景服務，將手指放開定位後，圖台便會切換到街景 功能，顯示該路段的實拍街景相關資訊。
53
圖 20 圖面點位資訊以及其詳細資料呈現
台北市政府提供的公開資料平台，在部分服務當中，提供了有關經緯度的地 理資訊，在選擇服務之後，便會利用這些經緯度資訊，將服務提供的點位資訊放 置在圖台上，每種不同的服務都有相對應的圖示。
點選點位圖示之後，會以氣泡框的方式將其中的詳細資訊帶出，其中包含簡 介、地址、電話、聯絡人、以及距離自己多遠等資訊，距離的部份採即時運算，
會依照使用者目前所在位置計算，利用的便是球面上弧長的公式。
54
圖 21 多點資訊經由 MarkerClusterer 處理後的畫面
由於公開資料平台的服務當中，有些服務的資料量龐大，會在地圖上繪製過 多的點，不但影響地圖呈現的效能，也會讓地圖變得不好閱讀，因此在這裡使用 了MarkerClusterer 這個元件來簡化點位的呈現。
當地圖進行縮放時，由於一個區域當中聚集的點較多，便會將這些點位轉成 一個Cluster 點，並顯示該區域點的數量，而當地圖逐漸放大至較小的比例尺區域 時，則會以顏色較淡的Cluster 點表示。
55
圖 22 使用者依角色切換圖層功能
使用者可以隨時切換欲查詢之圖層，可切換的圖層則是視使用者的角色來做 規劃，當圖層切換後，會立刻重新繪製地圖上的資訊點圖示，所以在這裡可能會 因圖台大量的存取動作而有操作上的延遲感。
56
圖 23 ”最近的資訊”功能畫面呈現
當使用者點選畫面右上的“最近的資訊”時，會跳出一個由 jQuery 設計的小對 話框，顯示距離使用者一公里內圖層上的訊息，當周圍沒有資訊時則會保留空白，
而在使用者一邊行進一邊操作地圖時，當使用者逐漸靠近其他點位資訊至一公里 內時，右上的按鈕則會開始閃爍，以提示使用者目前已經接近所查詢的目標圖層 當中的點了。
57
圖 24 多人同時定位畫面呈現
當多人同時在使用此系統時，每個使用者皆會在背景不斷的傳遞自己的位置，
並隨時接收系統中所有使用者的資訊，包含經緯度等，以便在畫面上呈現出來。
而因為效能考量，在設計上只繪製出畫面涵蓋範圍的使用者圖示，以減輕運算上 的負擔。多人定位圖示每隔25 秒即更新一次。
58
59
60
61
有關CPU 用量部分，當畫面沒有進行操作時，CPU 總用量皆不超過 5%，但 當使用者開始操作介面時，由於涉及到許多事件的觸發，CPU 就會提昇使用率來 處理這些事件。
62
第六章 結論與未來展望
第一節 研究成果探討
本研究的目的，在於建立一個模組化的工具集，以輕量化的伺服器作為服務 提供工具，經過驗證之後可以發現，node.js 在處理訊息跟 Web Socket 的速度非 常快，耗用的系統資源也相當低，足見透過V8 Engine 進行解譯的 node.js 非常適 合作為小型應用服務提供者。
而在應用程式的速度及反應方面，由於使用瀏覽器開啟的緣故，有時在速度 的表現上的確不如利用原生環境開發的軟體，而諸如手機軟體支援的訊息通知等 功能，也必須包裝成軟體才能使用；但在HTML5 標準下的功能都能執行無慮，
也不限定僅有手機可以使用，利用CSS 排版甚至可以做到對應平台呈現出不同的 使用者介面。
本系統未來可以針對以下幾個部分做改進：
1. 政府機關的公開資料平台是未來的一種趨勢，但目前僅有台北市政府提供公 開資料平台的服務，期望日後在其他縣市，也加入公開資料平台的服務，此 研究便可直接進行擴充。
63
2. 針對多人定位圖層及多方對談的部份，由於目前的採樣數量還不夠多，若是 在多人共同上線的情況下，系統對於Web Socket 處理上的負擔可能會加重。
3. jQuery moblie 所提供的轉場動畫，由於是跨頁面的 Ajax 動態呈現，有時會在 單一頁面上，造成頁面資料無法初始成功的情形，必須先行將所有頁面載入，
或是暫時關閉Ajax 的轉場效果，以達成畫面切換。
4. 目前使用的公開資料平台介接服務，是以有提供經緯度的服務資訊為主，僅 有住址的部份暫時沒有引入系統，由於將地址轉為經緯度必須經過服務作反 查，Google Maps JavaScript API 雖有提供相關服務，但由於免費的版本對單一 IP 的每天使用限制為 2500 筆，而且頻率不能夠過高，否則皆無法正常回應查 詢結果，因此在介接上並沒有採用此種作法。目前的權宜作法，是利用程式 在後端進行限制次數及頻率的批次反查，並將反查結果存回至資料庫以供查 詢，但這樣的作法缺乏即時性，而且必須額外經過前處理。
5. HTML5 還包含了 video、audio 等標籤定義，目前各家瀏覽器皆已個別實作出 對應的功能，只是目前各瀏覽器所使用的視訊／音訊編碼格式仍然尚未統一，
在檔案的支援上難免顧此失彼，日後規格統一化後，在實作上必定更為方便。
64
第二節 未來展望
由於HTML5 逐漸的成熟，現今許多手持裝置的軟體，如 iOS 以及 Android，
其實在開發上會選擇採用HTML5 標準規範，來開發網頁端的應用服務，再以中 介語言開發套件，將整個網頁系統封裝至軟體中。目前已有許多套件提供軟體封
其實在開發上會選擇採用HTML5 標準規範，來開發網頁端的應用服務，再以中 介語言開發套件，將整個網頁系統封裝至軟體中。目前已有許多套件提供軟體封