行政院國家科學委員會補助

大專學生參與專題研究計畫研究成果報告

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊ 計畫 ＊
＊ ： 情境感測式即時災害通報系統之設計與實作 ＊
＊ 名稱 ＊
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

執行計畫學生：陳志華
學生計畫編號：NSC95－2815－C－020－002－E
研 究 期 間 ：95 年 7 月 1 日至 96 年 2 月底止，計 8 個月
指 導 教 授 ：龔旭陽教授、蔡光榮教授

執 行 單 位：國立屏東科技大學土木工程系

中華民國 96 年 02 月 24 日
 摘要
近年來每逢大雨來臨，台灣各地均免不了受到淹水之苦，因此即時且
真實之水患資訊呈現，將視汛害防治與通報之關鍵。本計畫應用行動通訊
技術與多媒體軟體技術，規劃設計出一套防汛系統輔助防救災系統 - ”情
境感測式即時災害通報系統(A Real-time Situation-Aware Disasters System,
RSDS)”。RSDS 為三層架構式系統，包括行動使用者端、多媒體伺服器端、
及主動式資料庫伺服器端。RSDS 採用凸殼演算法和空間內插方法求算較
精確之 GIS/GPS 圖層判釋與定位功能，並應用 3D 虛擬實境技術針對災區
提供漫淹模擬，可使位於遠處人員能在任何地點查看各區域之相關地形圖
與虛擬實境災情模擬展示。此外使用者可以透過 GPRS/3G 手機、個人數
位助理(PDA)或平板電腦(Tablet PC)等行動式設備與遠端 RSDS 伺服器連
結並且進行溝通，即時地擷取所需之相關資訊，並於災區設置視訊監控及
影像傳輸，輔助現地資訊快速傳遞。

關鍵字：多媒體防汛系統、漫淹模擬、逃生路徑、行動式設備

ABSTRACT
When the heavy rainfalls or typhoons occur, many counties are
unavoidable to suffer the debris-flow and flood disasters in Taiwan. It is
urgently required to obtain the real-time disaster information to display the
situation, and it is important for people to design an effective disaster
information system to assist the disaster protection and alerting works. To
design a Real-time Situation-Aware Disasters System (RSDS), which is a
three-tier system composed of the mobile users, multimedia servers, and
disaster decision server, and the system combines mobile communication
technology. To accurately identify the disaster locations, RSDS system adopts
the Convex Hull Algorithm and Spatial Interpolation Methods to effectively
determine the GIS illustration and GPS position function. RSDS system also
provides the virtual flood disaster simulation and the determined emergent
escape route using 3D virtual reality technology. Therefore, based on RSDS
system, over general packet radio service (GPRS), 3G communication
network, personal digital assistants (PDA), tablet personal computers (Tablet
PC) or all kinds of mobile devices can real-time retrieve information including
news, pictures and multimedia.

Keywords: Multimedia Flood Prevention System, Flood Simulation, Escape

Route, Mobile devices.
一、前言
近年來臺灣所發生的自然災害日益嚴重，往往一場豪雨、一場地震過
後即引發嚴重的自然災害，進而造成人民生命財產的嚴重損失。2005 年 6
月豪雨與颱風(海棠、馬沙、泰利)不斷重創全省各區域後，2006 年 5 月豪
大雨與颱風(碧利斯、凱米、寶發)，年年幾乎無一縣(市)會倖免於難，例
如 0612 超大豪雨水淹屏東縣各鄉鎮市，另外 7 月強烈颱風海棠來襲，屏
東縣楓港大橋路基被洪水沖毀流失，造成恆春半島、南迴公路與高屏交通
完全中斷，造成恆春半島、南迴公路與高屏交通完全中斷，並在山地部落
多處發生走山或嚴重之邊坡災害，造成人民生命財產之損傷。有鑑於此，
建置一套功能完善且不受時空限制之即時災情通報系統，有效進行救災資
源分配與減輕人民生命財產損失的目標已成目前當務之急。因此當災害發
生時如何利用輕便的手持式設備(Handheld Devices)，透過無線行動通訊網
路實現即時(Real-Time)災情多媒體資訊(包括影像、聲音與文字等)傳輸，
已經是國科會國家型防救災計劃範疇內所選定的重要議題之一。然而，當
災害真正發生時，可能遭遇下列問題：
1. 災區實體有線通訊線路往往是斷線的，因此無法進行災情通報與
警示，且無法達到先前所預估之成效，進而造成災區嚴重的損傷。
2. 災害應變中心人員無法統籌性的了解災情分佈情況與各區域之災
情影響程度為何，進而造成救災資源分配不均等相關問題，無法
減緩及防堵災情之擴大。
3. 現場第一線防救災人員無法有效取得災情定位資訊與鄰近環境相
關地理資訊，無法有效提升救災效率。
4. 目前災情通報流程仍主採以有線電話進行報案，然而僅透過通報
者口語化的描述災情狀況，相關防災人員無法很明確的了解實際
災情狀況為何。
5. 在災區蒐集現地資料，需在家中或特定地方的電腦作輸入，無法
達到即時性的輸入資料，造成警訊無法即時通知。
6. 無線通訊網路之頻寬相當有限，如何有效提供平順之災區影像即
時傳輸，因此其必需透過相關壓縮技術，方能使資料量龐大的多
媒體影音資料在無線網路傳送上確保其即時性。
有鑑於此，本計畫將採用嵌入式多媒體通訊(Embedded Multimedia
Communication)技術規劃設計出可克服時空障礙限制的“情境感測式即時
災害通報系統(A Real-time Situation-Aware Disasters System, RSDS)”，
RSDS 使用者可利用輕巧且機動性高(High Mobility)之手持式設備，整合
無線行動通訊網路(3G/GPRS/GSM)進行即時性的災情多媒體串流服務
(Multimedia Stream Service)，並可依據使用者情境(Context Information)透
過標準化處理流程，進行情境資訊識別與表述分析，以提供品質調適之情
境感服務，此外本系統更結合客製化服務(Customized Services)、位置感
知服務(Location-Aware Service)、無線感測網路(Sensor Networks)、群體廣
播(Multicast)、網際網路地理資訊系統(Web GIS)、智慧型代理人(Intelligent
Agent)與虛擬實境(Virtual Reality, VR)等多項技術，建立即時有效的災情
現況通報與搶(救)災決策系統，並有效達成重大天然災害(如土石流、水
災、地震、山崩、森林火災等)之災情掌控監測、研判與救災決策下達，
確實發揮救災實質功能。
二、文獻探討
本計畫主要為提供使用者依據標準化之情境資訊處理分析流程，實現
情境感測之災害即時通報服務，其中相關研究文獻探討，本計畫依據其主
要議題範圍分類為(1) 災害防治、(2) 地理資訊系統、(3) 多媒體串流與(4)
情境感知四部份，以下將分別進行探討敘述。

2.1 災害防治相關文獻探討
近幾年國內外學術界已有一些洪水災害防治之相關研究，針對洪水漫
淹模式，顏利玲學者所提出之淹水災情回報與推估主要設計為預先設置固
定點位及標尺，並將已編號的各點座標及地表高程建置資料庫，透過淹水
深度及時間之災情回報，再將 DTM 資料、標尺點位座標資料、災情回報
資料及堤防外推估無效之標定區域圖輸入至洪水推估機制運用距離反比
權重法(the Inverse Distance Weighted approach, IDW)進行分析(顏利玲
2001)。在 IDW 空間內插法的運用上雖提供精確之災情推估，但由於該內
插法需大量運算，因此所提之模式需進行改善，以減少運算時間與伺服器
負載。此外其資料結構及操作使用上卻僅限於二維平面，無法將坡度、坡
向和整體漫淹情況完整呈現出來，而在設計上較偏重於一般個人電腦之使
用，故在使用上並不具高度行動力且當災區網路斷線時此系統便不能發揮
其固有之功效。

2.2 地理資訊系統相關文獻探討
由陳泰弘學者所提出之以多視景虛擬實境建立網際三維地理資訊系
統，主要利用 2D GIS 平面建物圖徵轉換成 3D 之 VRML 資料格式通則所
建立，將 2D 空間資料分離並匯出，再經由三度空間繪圖工具拉高 2D 建
物圖徵，輸出成 VRML 檔案格式，最後利用 VRML 編輯工具加上屬性製
成(陳泰弘 2001)。雖提供完整之三維地理資訊，但其系統卻沒有結合 GPS
進行定位點展示，且無法動態加入 3D 物件，因此在應用上只能呈現原本
已編輯好之虛擬實境，並不能依使用者之需求即時進行更新，故需結合座
標與數位高程，以提供 3D 物件新增、編輯功能，提供更完整之 3D 虛擬
實境展示。
在救災系統中傳統逃生路線模擬方面，陳樹群教授提出災害危險區疏
散避難規劃，主要為利用基本資料調查彙整法進行災區資訊與相關路徑之
現場蒐集，並訪問相關人員與住戶進行逃生路線規劃後，將收集之基本圖
層與疏散路線圖進行套疊並重新繪製出相關之逃生路線圖，再分發給與民
眾(陳樹群 2002)。但此設計需耗費大量的人力進行宣導，且當災害發生
時道路被洪災淹沒或當道路修正等因素發生時無法給予最即時之逃生資
訊。
Cove and Johnson 在 2003 年所提出之利用車道基礎來建立車道途徑
規劃模型，用來降低交通延遲，提升十字路口的疏散，以最小成本流量為
目標式，利用整數規劃對簡易路網導出最佳的路徑規劃(Cove and Johnson
2003)。如此之設計雖然相當完善，但應用此方式必須要靠許多救難人員
的導引及疏散者互相配合，才能發揮疏散效率，並且當災害發生時，時間
和安全性為首要之考量，故避難路徑規劃上並不完全只依靠流量因子，需
考慮其他影響因子(如路程遠近、坡度與道路平穩等)，其對救災效能必定
能再提升。

2.3 多媒體串流相關文獻探討
近年來由於資訊科技術不斷地進步，手持式設備已進入普及化的階
段，人們透過輕便的設備來進行多媒體服務應用為時勢所趨，因此相關的
研究議題吸引了許多學者從事研究，其中如何於嵌入式系統上提供調適性
之多媒體串流服務，國內外就有不少學者提出相關的解決辦法，例如針對
在嵌入式設備進行即時影像串流之探討，Lim 等學者提出一架構在
MPEG-4 影像壓縮標準上，於 PDA 等嵌入式設備透過無線分封交換服務
(General Packet Radio Service, GPRS)進行即時影像串流系統(Lim et al.,
2003)。此篇論文主要著重在改善 MPEG-4 編碼器與解碼器之編碼演算
法，雖然因考量 PDA 有限之運算能力而對演算法進行最佳化，但無考慮
PDA 記憶體容量小與電力消耗等問題。此外亦有部份學者針對多流之服
務品質(Quality of Service, QoS)控制進行研究，如 Masugi 學者提出，多媒
體串流品質調適服務中主要依據傳輸層(Transport layer)的封包遺失率
(Packet Loss Rate)、傳輸延遲(Transmission Delay)與應用層(Application
layer) 之 緩 衝 區 使 用 率 (Buffer Usage Rate) 、 影 像 傳 輸 速 率 (Video
transmission rate)為主要控制影響因素，用以進行串流服務品質之調適控
制，然而現階段多數之多媒體串流服務研究中，對於情境資訊的處理卻大
多無一統一標準流程，導致相關多媒體服務元件間無法有效進行資訊交流
分享(Masugi, et al., 2005)。

2.4 情境感知相關文獻探討
針對普及運算環境(Pervasive Computing Environment)中情境因素來
源過於分散，且情境資訊表達方式與完整性不一致的問題，Gu、Chen 與
Korpipää 等多位學者，相繼提出利用本體論(Ontology)建構語意情境資訊
(Semantic Context Information)方法，以便進行情境資訊的識別推論，其中
Korpipää 等學者針對情境識別與情境表述兩項功能需求，設計一套標準化
作業流程，首先針對未經處理情境資料(Raw Context Data)的識別或特徵粹
取(Feature Extraction)，Korpipää 等學者依據情境因子特性分別採用明確界
限(Crisp Limits)與模糊集合(Fuzzy Set)兩項識別方法進行特徵粹取，而對
於情境資訊的描述，主要為利用 W3C 所制定之資源描述架構(Resource
Description Framework, RDF)定義情境資訊本體詞彙，提供語意化的情境
資訊描述，其中並透過情境類別(Context Type)、情境值(Context Value)、
情境信度值(Confidence)、情境來源(Source)、時間戳記(Timestamp)與屬性
(Attributes)等六項屬性進行情境資訊描述，對於較高層級之情境狀態資訊
之取得則透過貝氐定理(Bayesian reasoning)進行推論表述，然而由於 RDF
與 RDF Schema 所提供之資料構詞較為簡單，因此於建置情境資訊本體詞
彙上將會有所限制，無法充分表達出實體情境資訊之本體論架構，因此仍
有改善空間(Gu et al., 2005; Chen et al., 2003; Korpipää et al., 2003)。
由於 RDF 與 RDF Schema 提供構詞較有限之問題，Gu 等學者即針對
普及運算環境(Pervasive Computing Environment)特性提出一服務導向之
情境感知中介軟體(Service-Oriented Context-Aware Middleware, SOCAM)
架構，該架構主要採用較為新穎之網站本體語言(Web Ontology Language,
OWL)，SOCAM 透過 OWL 所提供之較為完善的本體論構詞建構出情境
資訊領域知識描述，以便達到情境資訊的語義描述(Representation)、情境
推論(Reasoning)與情境分類(Classification)或相依性(Dependency)設計等
功能，研究中採用了二階層(Tow-layer hierarchical)方法來設計情境本體
論 ， 主 要 將 情 境 資 訊 獨 立 分 割 為 兩 大 類 別 ， 分 別 為 Common Upper
Ontology 與 Domain-Specific Ontologies 兩 類 ， 其 中 Domain-Specific
Ontologies 主為收集較低層級之情境資料，而 Common Upper Ontology 則
是由多個 Domain-Specific Ontologies 來進行推導，當使用者改變領域時
Domain-Specific Ontologies 將會自動的進行調適切換，以符合使用者情境
需求，如此之分割方式可達到(1) 簡化情境知識的規模與(2) 減輕情境資
訊處理所產生的負擔(Gu et al., 2005)。雖說 SOCAM 提供相當完整且標準
化的情境感知服務架構與流程，然而其中仍有部份問題未被詳細定義與說
明，例如(1) SOCAM 僅以條例式規則(Rules based)建置情境推論模式判斷
調適性服務之規則，將造成服務開發者撰寫程式上的困難，其原因為情境
資訊大部份是由多個情境元素所組成，其組合方式相當多變，因此根本無
法單純以條例規則方式定義各種情境組合下的調適控制為何。(2) SOCAM
對於情境衝突(Context-Conflict)僅大略提及情境衝突之發生情況，但並未
設計相關的應對方法。(3) 情境推論(Context Reasoning)結果大都屬於絕對
性質的，無法有效對映於底層多媒體串流服務之調適控制上。
有鑑於上述相關系統所衍生之問題，“情境感測式即時災害通報系統
(A Real-time Situation-Aware Disasters System, RSDS)”設計原則與功能包
括：(1) 災害發生時可利用輕便的手持式設備(Handheld Devices)，如 Tablet
PC、PDA 及手機等，透過無線通訊網路傳輸即時(Real-Time)災情多媒體
資訊(包括影像、聲音與文字等)。(2) 因洪水漫淹災害發生為隨機事件，
因此進行研判應具即時性(Real-time)之功能，立即執行災情回報與災情推
估，並且本系統亦有考慮到當網路斷線時，直接採用 PDA 上所設計之漫
淹模式及最適路徑演算法進行推理輔助研判。(3) 為確實有效快速推估災
情，本計畫運用凸殼演算法(Convex Hull Algorithm, CH)提供快速運算之災
情 漫 淹 推 估 ， 並 提 出 線 性 距 離 加 權 法 (the Linear Distance Weighted
approach, LDW)以進行精確之洪水漫淹推估，以確實達到漫淹模擬展示。
(4) 災害發生時可迅速規劃一條快速且安全之最適避難路徑，讓民眾快速
且安全到達避難中心，本計畫針對災區地形提出最短路徑與最平穩路徑兩
種模式，以因應使用者之情境與需求進行最適路徑之推論與展示。
三、研究背景
目前已進入 3G 寬頻時代，手機的應用除了傳統的語音服務外，在資
料的傳輸、行動多媒體、行動商務的應用會更為廣泛。台灣地區隨著無線
與行動通訊環境的演進，無線數據服務的應用廣泛，將可預期的，原本在
2G 時代的簡訊服務(Short Message Service, SMS)而需漸漸轉為多媒體的
應用，隨時上線的(always-on data environment)的 3G 時代來臨，多媒體與
簡 訊 服 務 (Multimedia Messaging Service, MMS) 以 及 行 動 定 位 (Mobile
Location-based Service, MLS)的服務也會加入系統的考量中，因此要架構
RSDS 系 統 所 需 探 討 之 相 關 技 術 包 括 (1) 普 及 運 算 (Pervasive
Computing) 、 (2) 情 境 感 知 服 務 (Context Aware Service) 、 (3) 本 體 論
(Ontology)、(4) 網站本體語言(Web Ontology Language , OWL)、(5) 嵌入
式資料庫系統同步、(6) 虛擬實境(Virtual Reality, VR)、(7) 距離倒數加權
法(the Inverse Distance Weighted approach, IDW)，以及(8) 最短路徑演算法
(The-Shortest Path Algorithm, SPA)等技術，以下分別進行述說。

3.1 普及運算(Pervasive Computing)

普及運算的概念最早是由 Weiser 於 1988 年提出，當時被命名為泛在
運算 (Ubiquitous Computing)，簡稱為“Ubicomp”，Weiser 認為所有的運算
裝置皆存在於每一角落中，隨處可及並無所不在，且可依人們的生活經驗
進行適當的運算，滿足人們的需求。到了 1998 年 IBM 將 Ubicomp 的概
念 引 進 並 將 其 更 名 為 普 及 運 算 (Pervasive Computing) ， Ubiquitous 與
Pervasive 的觀念可由終端設備資訊交換的形式來做區別，Ubiquitous 中終
端設備間則透過網路進行彼此間的資訊交換，而 Pervasive 中的終端設備
則必須有一伺服器做為資訊的交換中心[2]，本計畫所開發之系統即採用
Pervasive 觀念，由情境管理代理人集中管理所有參與服務之相關實體的
情境資訊。
以往人們利用大型的電腦來為多個使用者進行各式各樣的運算活
動；後來由於個人電腦的日益普及，不但電腦的體積變小了，也漸漸取代
了大型電腦所扮演的角色，且一台個人電腦僅為一個使用進行相關的計算
活動；近年來隨著資訊科技的成長，使用者不再使用單一的設備來執行所
有的工作，而是利用各種可能支援運算的裝置，例如 PDA、Tablet PC 與
SmartPhone 等共同執行，進而解決使用者的問題，普及運算(Pervasive
Computing) 為 一 般 性 電 腦 運 算 的 拓 展 ， 多 數 以 小 型 的 嵌 入 式 系 統
(Embedded System)方式存在，而具有運算能力的設備，因而可創造無所
不在的計算環境，其範疇可包括各種移動設備，例如 PDA、Tablet PC 與
Smart Phone 等智慧型裝置，甚至可以應用於各種電器用品，這些裝置的
本身都具備有簡單的運算能力，同時可與有線或無線網路進行連接，進而
讓使用者可隨時隨地獲取所需資訊[1]。
3.2 情境感知服務(Context-Aware Service)
情境感知服務概念為位置認知(Location-aware)服務之延伸，所謂位置
感知服務即可依據使用者所處地理位置，傳輸使用者所需資訊，然而當使
用者進行移動時，透過相關感測器(Sensor)仍可持續取得使用者即時定位
位置資訊，進行更新調適其服務內容，讓使用者可不需被限制於特定位置
進行資訊服務需求[17]，近年來隨著新穎技術的不斷發展，情境資訊
(Context Information)已不在侷限於定位位置資訊，由 Dey 等學者提出之情
境資訊定義為“Context is any information that can be used to characterize the
situation of an entity.”，即任何與實體(Entity)有關之特徵資訊皆屬之，而所
謂實體即包含使用者、應用程式與周遭環境實體等等，因此描述人、事、
時、地、物等實體特徵的資訊皆為情境資訊[4]，由於情境資訊的組成相
當複雜，因此 Chen 等學者依據情境因素特性，將其大略歸類為下列幾項
[3]。
1. 計算情境(Computing context)：網路連線狀態、設備電力狀態、展
示螢幕大小、通訊費用、網路頻寬或鄰近資源，如印表機、顯示
器與其它工作站等，皆屬於計算情境。
2. 使用者情境(User context)：使用者記錄檔、定位位置資訊、使用
者活動狀態、使用者時程安排(Schedules)、鄰近的使用者、甚至
當時的生活群體狀態(Social Situation)皆屬之。
3. 實體情境(Physical context)：光照、噪音程度、交通狀況、溫度、
空氣品質等。
4. 時間情境(Time context)：如每天、每周、每月的某個時刻或哪個
季節。
情境感知服務主要為依據上述分類之情境因素，提供動態且自動化之
服務變動調整，以符合實際情境環境的變化，然而對於情境感知服務的模
式 類 型 ， Chen 等 學 者 亦 將 其 分 類 為 主 動 情 境 感 知 (Active Context
Awareness)與被動情境感知(Passive Context Awareness)兩項，以下即針對
兩類服務類型進行簡要說明[3] [11]。
1. 主動情境感知：所謂主動情境感知即應用程式或設備可自行依據
所蒐集處理之情境資訊，自動進行服務的調整，所有調適動作皆
由應用程式自行進行觸發與控制，不需透過使用者進行設定。
2. 被動情境感知：由應用程式自行蒐集處理相關情境資訊，當所更
新之情境資訊為使用者所需或有感到興趣的，則應用程式將會告
知使用者該情境資訊發生更動，再由使用者決定調適控制，此外
應用程式亦可將情境資訊儲存保留，當使用者有需要時再進行取
用。
近年來由於行動通訊網路環境技術已逐漸成熟，輕便之手持式設備也
越來越普及化了，為了能有效提升其實用性與降低操作複雜程度，因此情
境感知服務相關研究已成為相當熱門之研究議題，本計畫即針對目前情境
感知服務相關研究領域進行分類，其分類結果如圖 1 所示，以下即針對各
項研究分類作一分述說明。
 圖 1：情境感知研究議題分類

1. 情境處理(Context Process)：於現實環境中，情境資訊的來源相當
廣泛，因此如何依據相關標準進行情境資訊判斷是一項相當必要
的處理，其中包含了情境識別(Context Recognition)與情境表述
(Context Representation)兩步驟，情境識別主要為針對未經處理之
情境資料(Raw Context Data)進行特徵粹取(Feature Extraction)，用
以取得較低層級(Lower Level)之情境因子(Context Atoms)，目前對
於特徵識別，主要以明確界限(Crisp Limits)與模糊集合(Fuzzy Set)
兩項識別方法為主，當較低層級之情境因子識別完畢後，即可透
過相關情境因子辨別高層級(Higher Level)之情境資訊為何，此辨
別過程即為情境表述，情境表述可透過本體詞彙分類或特徵因子
的選取等方式進行推論。
2. 應用調適(Application Adaptation)：主要針對情境內容所提供之應
用調適控制機制進行設計與探討，例如當使用者情境顯示為參與
會議時，則手機與相關手持式設備即自動調適設定為靜音等運
用，其中更可依據過往情境歷史記錄進行預測與學習，以提供合
適之調適服務建議供使用者參考。
3. 情境衝突(Context Conflict)：當有限資源受到多數情境調適機制的
管理時，即可能發生情境衝突之現象，對於情境衝突之控制大都
分為衝突偵測(Conflict Detection)與衝突調解(Conflict Resolution)
兩步驟，衝突偵測主要依據調適控制內容與同時間區段內相關調
適紀錄進行衝突偵測，當衝突發生時，可根據使用者屬性或各情
境因子之權重與優先權進行衝突調解推論與控制。
4. 感測來源(Sensor Source)：情境資訊的來源相當廣泛，因此有部份
研究即專門針對感測來源進行設計與探討，例如穿戴式設備
(Wearable Device)、感測設備 (Sensor Device)、無線射頻辨識技術
系統(RFID System)與感測網路(Sensor Network)等皆可做為情境
資訊來源感測裝置。
5. 中介軟體(Middleware)：由於相關情境感知服務架構大多數皆建置
於普及運算或泛在運算(Ubiquitous Computing)環境中，因此並沒
有一固定之網路架構，所有相關元件皆屬於分散式的，因此元件
模組間，必需設計相關中介軟體以提供連線管理(Connectivity
Management) 、 服 務 遷 移 (Service Migration) 、 架 構 管 理
 (Configuration Management)與事件登記(Event Register)等服務，用
以因應普及運算與泛在運算環境特色與限制。

3.3 本體論(Ontology)
於 人 工 智 慧 領 域 中 本 體 論 (Ontology) 為 用 來 定 義 解 釋 一 個 領 域
(Domain)的知識核心內容，以便達到知識描述進而提供知識共享與交流之
基礎。根據 Gruber 學者對於本體論的定義為“An ontology is a formal,
explicit specification of a shared conceptualization.”[10]，因此本體論可運用
於 表 達 解 釋 與 明 確 定 義 某 領 域 知 識 (Domain Know How) 中 的 詞 彙
(Vocabulary)，並能說明詞彙間彼此的關連性，本體論所表達出來的知識
具備了物件導向、特殊化與可推論性等三項特性，其構成份子包含了物件
(Object) 、 類 別 (Class) 、 屬 性 值 (Value) 與 各 物 件 類 別 之 間 的 關 係 屬 性
(Relationship Properties)，使該知識內容架構擁有明確的知識集合定義，藉
此有系統的知識集合定義，提供了程式可理解的基礎知識內容，相關應用
軟體程式彼此間可透過此基礎進行知識的分享、溝通，進而達成一個有共
識的知識傳遞媒介。
知識本體論可運用詞彙有系統的表述某領域的知識，其用意即為將人
類語意(Semantics)層次知識概念加入於相關應用服務之中，例如概念式搜
尋和瀏覽、網際網路搜尋、個人化服務、程序自動化服務等，本體論的呈
現特定領域的知識核心，可促使相關應用系統程式或服務代理人能夠理解
各類資訊所表達的意思，以利進行資料處理與事實結果的推論[6][7]，然
而於普及運算環境中之情境感知服務，由於情境資訊的來源相當分散且不
一致，因如何以統一的方式來識別與描述使用者情境狀態為一必需探討的
研究議題，近年來相關學者已開始將本體論概念整合運用於情境感知服務
中，其主要優點與效益為(1) 於開放動態的分散式系統架構中，本體論的
方法將能提供一公眾認同的知識分享模式，以進行有效率的情境資訊交
流，(2) 透過本體論可有系統的明確定義宣告詞彙，提供了標準化的情境
資訊分析模式，待各分散的情境來源感測結果收集後，可進行語義化情境
資訊描述推論，快速且正確的推論判斷使用者所擁有的情境狀態為何，(3)
明確的情境資訊表述有利於進行情境資訊的調適機制推理與相關情境衝
突的偵測調解[3][11][12]。

3.4 網站本體語言(Web Ontology Language , OWL)

網站本體語言(OWL)為 W3C’s Web Ontology Working Group 於 2004
年所發表制定之標準，主要為提供網站內容正式的語意與附加詞彙描述，
進而將網頁資源、資料儲存與處理流程以語意化的方式進行關連，使得這
些內容比僅由可延伸標記語言(Extensible Markup Language, XML)、資源
描述架構(Resource Description Framework, RDF)所支援的網路內容讓更
多的機器可以更容易解讀，因此換言之 OWL 亦為建置語意網(Semantic
Web)的一項新穎標準技術。網站本體語言(OWL)是為處理資訊內容的應用
程式而設計，不是給人類呈現資訊用的，因此與目前之可延伸標記語言
(XML)其基本設計目的有所差異，此外 OWL 其能力亦較資源描述格式
(RDF)強大，以下即針對 XML、OWL、RDF 與 RDF Schema 作一簡要差
異描述[8][18]。
1. XML：為一套用來表達資料結構的通用語法，XML 把資料的種
文件語法規則，使用者可以自行定義資料標記(Tag)進行文件結構
的表達，此外 XML 亦提供命名空間(Namespace)的宣告，用以區
分不同領域的標記，然而 XML 僅能對於單一份 XML 文件進行描
述，並無法描述與其它 XML 文件之間的關聯性，因此亦無法提
供語意功能。
2. RDF：是一種資料模型，為用來描述資料的資料(Data About
Data)，亦可稱為元數據(Metadata)，可描述物件“資源”彼此之間的
關係，定義了各領域描述資源的規則，這種資料模型提供了一種
簡單的語意能力，RDF 模型中最基本的元素分別為主體資源
(Subject)、述語(Predicate)與目的資源(Object)，其宣告使用方式為
主體資源藉由述語(即主體資源屬性)與目的資源產生連結，形成
資源與資源間互相的關係連結。
3. RDF Schema：而另外 W3C 亦制定了資源描述架構綱要(RDF
Schema)用來描述 RDF 資源類別可以採用的屬性(Property)詞
彙，並且描述每個屬性的意義、特性與屬性值的限制，因此 RDF
Schema 為 RDF 之元數據(Metadata)，RDF Schema 所提供之詞彙
包 含 類 別 (rdfs:Class) 、 子 類 別 (rdfs:subClassOf) 、 屬 性
(rdfs:Property) 、 子 屬 性 (rdfs:subPropertyOf) 、 定 義 領 域
(rdfs:domain)、值域(rdfs:range)與個體(Individual)等等，然而 RDF
與 RDF Schema 所提供之資料模型較為簡單，因此於建置情境資
訊本體詞彙上將會有所限制。
4. OWL：提供用來正式描述網站文件中的專門用語，OWL 新增了
更多的詞彙來描述這些屬性與類別，所包含之構詞(Constructs)資
料如表 2-1 所示，其中例如類別等價(equivalentClass)、屬性等價
(equivalentProperty)、個體等價(sameAs)與個體相異(differentFrom)
等屬性之構詞皆為 XML、RDF 與 RDF Schema 所無法支援的，因
此藉由 OWL 將可建置較為完備且較符合現實環境之情境資訊本
體論。

3.5 嵌入式資料庫系統同步
複寫模式分為快照式複寫、交易式複寫和合併式複寫三種[22]。其中
「合併式複寫」(Merge Replication)，為合併訂閱者與發行者對於資料庫
所作的改變，產生一致性的資料庫內容。合併式複寫適用在 PDA 客戶端
的使用者無法時常與伺服器連線，卻又要保持資料庫一致性。SQL CE 中
複寫的架構如圖 2 所示，合併式複寫架構元件分為「SQL Server CE 資料
庫引擎」、「SQL Server CE 用戶端代理人」、 「SQL Server CE 伺服器端
代理人」和「SQL Server CE 複寫供應者」四個部份。
 SQL Server CE 資料庫
行 應用程式
動
式
使
用
者 SQL Server CE SQL Server CE
端 用戶端代理人 資料庫引擎

.in
IIS

SQL Server CE
伺服器端代理人

服 SQL Server 協調者

.out
器
SQL Server SQL Server CE
端 複寫供應者 複寫供應者

SQL Server 資料庫

圖 2：SQL CE 中複寫運作架構

1. 「SQL Server CE 資料庫引擎」是管理客戶端之 WinCE 裝置的資

料庫。 「SQL Server CE 資料庫引擎」會記錄每一個資料交易處理
(Transaction)，在客戶端 WinCE 裝置與伺服器端 SQL Server 連接
時進行合併式複寫，並將變動過後的紀錄傳回 SQL Server 中，以
保持雙方資料庫的一致性。
2. 「 SQL Server CE 用 戶 端 代 理 人 」 提 供 應 用 程 式 所 有 複 寫
(Replication)的方法，當 WinCE 資料庫要與 SQL Server 伺服器進
行資料同步時， 「SQL Server CE 用戶端代理人」會把變動後的資
料，經 HTTP 協定傳到「SQL Sever CE 伺服器端代理人」。當伺
服器端 SQL Server 發行者傳送發行集上變更之資料給 SQL server
for WinCE 之訂閱者時，「SQL Server CE 伺服器端代理人」會將
變動過的資料傳送給用戶端代理人，用戶端代理人再由「SQL
Server 資料庫引擎」變更資料庫中的資料，因此與伺服器中的資
料庫保持一致性。
 3. 「 SQL Server CE 用 戶 端 代 理 人 」 提 供 應 用 程 式 所 有 複 寫
(Replication)的方法，當 WinCE 資料庫要與 SQL Server 伺服器進
行資料同步時， 「SQL Server CE 用戶端代理人」會把變動後的資
料，經 HTTP 協定傳到「SQL Sever CE 伺服器端代理人」。當伺
服器端 SQL Server 發行者傳送發行集上變更之資料給 SQL server
for WinCE 之訂閱者時，「SQL Server CE 伺服器端代理人」會將
變動過的資料傳送給用戶端代理人，用戶端代理人再由「SQL
Server 資料庫引擎」變更資料庫中的資料，因此與伺服器中的資
料庫保持一致性。
4. 「SQL Server CE 伺服器端代理人」負責處理「SQL Server CE 用
戶端代理人」所傳過來的要求。當客戶端 SQL server for WinCE
與伺服器端的 SQL 資料庫同步時，此代理人在 IIS 伺服器上建立
一輸入檔 (.in)，並將用戶端代理人傳過來的資料庫變動寫到此檔
案後，伺服器端代理人呼叫「SQL Server 協調者(Reconciler)」處
理輸入檔中之資料並產生一輸出檔(.out)，此即「發行者」對「發
行集」資料之更新。最後伺服器端代理人將此檔案傳回給用戶端
代理人，對「訂閱者」的資料庫進行更新。
「SQL Server CE 複寫供應者(Replication Provider)」之功能在為 SQL
Server CE 協調者處理輸入檔與輸出檔。當資料庫進行同步時，「SQL
Server CE 協調者」要求「SQL Server CE 複寫供應者」讀取輸入檔並回
報給「SQL Server CE 協調者」 ，因此發行者將獲得 SQL server for WinCE
此訂閱者對伺服器端資料庫所作之改變。另外「SQL Server 協調者」也
會告知「SQL Server CE 複寫供應者」在發行者資料庫所做之改變， 「SQL
Server CE 複寫供應者」再將此改變寫到輸出檔中。

3.6 虛擬實境(Virtual Reality, VR)

虛擬實境(Virtual Reality, VR)不像傳統的 2D 介面，人類只能被動地
接受固定的視覺角度、聲音來源，甚至無法感受傳統介面內容中所傳遞的
各種感覺，但是現今在虛擬實境的發展之下所傳達的內容可以經過電腦的
處理幻化成為一個虛擬世界，人類可以主動改其視角以及音源的方位，透
過電腦運算的結果以視覺和聽覺的感知器來感受這個虛擬世界，或是透過
觸覺或回饋的裝置來感覺在傳統介面中從未有的真實感受，並且和其互動
達到和真實世界相似的操作介面和環境。VR 分為以下兩種：
1. 模型式虛擬實境(Model-Based VR)：為傳統式的虛擬實境，需塑
型（Modeling）、顯像（Rendering）。優點是立體視覺效果逼真，
缺點是成本很高，因為建造 3D 模型費時費力、需要硬體加速配
備、場景的複雜度及逼真度受限於電腦。
2. 影像式虛擬實境(Image-Based VR)：主要是建構在一個立體圓柱當
中。以照相機拍攝一組頭尾相接的連續照片來模擬的真實環境，
以快速連續撥放達到流暢的動畫效果。做法是將照片轉換成電腦
圖檔後，銜接成一個立體圓柱面。假想使用者進入虛擬世界後，
 他的視線便是位於立體圓柱當中隨著使用者視界的上下左右移
動、放大或縮小，系統動態地將視界內的圖像經過影像處理，製
作出使用者正常見到的立體場景的圖像。使用者在虛擬空間中移
動，便是經由一連串的圖像轉換的結果，優點是不需硬體加速配
備，成本較低且顯像品質細緻和虛擬場景製作方便 (無場複雜度
的限制)，缺點是立體視覺效果較差。
虛擬實境標記語言(Virtual Reality Modeling Language, VRML)是一套
與全球資訊網結合用來描述 3D 虛擬世界的一種語言，可用來建立 3D 空
間物件、景像，以及虛擬實境的展示模型。而目前較新的 VRML 2.0 更加
入了與使用者互動能力，讓使用者可以與全球資訊網上的立體景像有互動
(Interaction)的溝通方式，使用者可以利用滑鼠的操作，在 3D 立體虛擬空
間中移動視點角度，令人有置身其中般的感覺。
VR 為”模擬出一個虛擬的環境，使用者可在其中任意漫遊，且能在任
何位置、以任何角度來觀看週遭的世界，並與環境中的物體發生互
動”[9]。虛擬實境模組語言(Virtual Reality Modeling Language, VRML)是為
一套虛擬實境描述語言，用來與全球資訊網(World Wide Web, WWW)結合
[19]，用來描述三度空間互動世界的一種檔案格式，其內容是為一純文字
的檔案，允許在”低頻寬”的網路上運作。
以座標系統和節點介紹 VRML 概念可分如下：
1. 座標系統
在 VRML 中 採 用 的 是 卡 氏 右 手 立 體 座 標 系 統 (Cartesian
Right-Handed Dimensional System)，如圖 3 所示，量測長度和距離的
基本單位是公尺，而量測角度的的基本單位是弧度(弳)。
2. 節點
VRML 以節點(nodes)為基礎，每個節點都具有以下四項特性：
(1) 節點種類：如立方體、錐體、材質圖...等。
(2) 節點參數：稱為「參數場」(fields)，節點可以有零或多個參數。
(3) 節點名稱：VRML 中的節點不一定要指定名稱，但若指定名
稱則必須唯一。
(4) 子節點：節點與節點之間可以有階層式的從屬關係。具有子
節點的節點稱為「群節點」(group nodes)，群節點可以有零或
多個子節點。
目前最新的版本是 VRML2.0，增加了描述動作的語法與所需的節點
型態，另外可支援 script 的語法，像是 javascript、vbscript 等，並可結合
多媒體的檔案以增加場景的豐富性與真實性，也因此 VRML 所建構的虛
擬世界愈來愈逼真了。
除了利用地理資訊系統進行展示外，亦可透過虛擬實境之技術來展示
地圖地貌，並可以針對所需查看之視點，進行模擬、拉近或拉遠等功能。
現今在虛擬實境相關技術發展之下，所傳達之內容可以經過電腦處理轉化
成為一個虛擬世界[24]。因此本計畫中將以 GIS 資訊與 VR 進行整合，並
透過 VR 進行情境感知防汛之模擬與展示。
 圖 3：卡氏右手立體座標系統

圖 4：屏東科技大學虛擬實境模型圖

目前一般的災情通報都屬於較平面的通報(如文字或是地形影像)，雖
說如此即可達到事先通報使用者土石流即將發生之功能，但卻無法清楚的
交待使用者其目前所處位置之地形及土石流預測流動路徑為何，所幸近來
由於電腦技術不斷的提升，及虛擬實境技術的快速發展，已將以往只能在
高效能大型主機上發展的虛擬實境、3D 空間繪圖技術漸漸地普及化，因
為 VRML 所撰寫出之程式碼小且可攜性高，故可在一般個人電腦上展
示，同樣也可在個人數位助理( PDA)亦能展示相關 3D 數值地形圖，讓行
動式使用者端輕鬆進入相關虛擬實境之環境。因此本系統將利用虛擬實境
方式來模擬地形，讓使用者快速了解其當地之地形與逃生資訊。
在本計畫中虛擬實境(Virtual Reality, VR)之設計是讓在現地探察的使
用者或位於遠處的專家能在任何地點使用此功能查看各區域之相關地形
圖及虛擬實境災情模擬展示。透由 VRML 程式語言來撰寫此一功能並結
合在系統中，因 VRML 語言撰寫產生之程式碼檔案較小，故有利於在
GPRS 上傳送相關檔案與模擬情況。經由行動通訊網路、無線網路的環境
或一般有線網路傳輸較大或較精確之地形圖時，運算繪圖仍極耗費系統資
源，目前一般 PC 大都還能負荷，但 Tablet PC 之效能並不像 PC 般功能強
大，因此利用 Tablet PC 開啟較大的 VR 地形圖時，其所花費處理時間也
相對地較長，亦不能像在 PC 端一樣的快速移動視點，有時甚至出現延遲
展示之情形，另外 Tablet PC 之螢幕展視畫面並不像一般主機，其解析度
亦會較低，基於以上理由將全台灣的立體地形圖依經緯度分別切割成多個
小區塊，並把較常發生災害與發生機率較高之地區獨立切割出來。在分割
同時也藉由該軟體將各區塊之地形解析度及格數調高，惟各區塊之經緯度
必需紀錄在後端的 MS-SQL 資料庫中，當前端之 Tablet PC 使用者利用
GPS 所取得當地經緯度或輸入欲查看區域座標時，系統即會尋找該區域座
落在哪個區塊中，並直接呼叫出該區塊的 VR 地形檔，此方式即可提供解
析度高並且較不失真的立體地形給使用者參考，因為圖形較小且切割出之
圖形精緻度提高，故在 Tablet PC 上能展示出較佳之效果與效能。

3.7 距離倒數加權法(the Inverse Distance Weighted approach,

IDW)
IDW 是一個加權平均插值法，也是屬於精確的插值法，可以進行確
切的或者圓滑的模式插值。次方參數控制著加權係數如何隨著離開一個觀
測點距離的增加而下降。對於一個較大的次方，較近的數據觀測點被給定
一個較高的權重份額，對於一個較小的次方，權重比較均勻地分發給各數
據觀測點。當計算一個觀測點時，配給的權重是一個分數，所有權重的總
和等於 1.0[34]。IDW 模式普遍如公式(1)：
s
1
∑z
i =1
i
d ik
Z0 = s ………………………………………………….…公式(1)
1
∑i =1 d i
k

距離倒數法的特徵之一是要在網格區域內產生圍繞觀測點位置的零
散(odd)。用距離倒數網格化時可以指定一個圓滑參數。大於零的圓滑參
數保證，對於一個特定的結點，沒有哪個觀測點被賦予全部的權值，即使
觀測點與該結點重合也是如此。 圓滑參數透過修飾均勻已被插值的網格
來降低零散(odd)影響。這種內插方式是以現有的已知點數值來做線性加
權運算，權重的大小依據點位資料的距離來決定。

3.8 最短路徑演算法(The-Shortest Path Algorithm, SPA)

以往地理資訊系統利用傳統地圖在保存、更新或查詢上均不如數值資
料快速且簡便。因此，若將地圖所包含的資料全部轉換成電腦能處理的數
值資料存在資料庫內，建立逃生的模式後則可對資料進行更有效率的維護
更新，也能作更快速、更複雜的分析處理[23]。
針對逃生模式之建立，因考慮逃生人員所需花費之逃生時間、安全性
與其它重要相關因素，故先考量避難所之位置[30][35]，再加以推論其他
相關因子，得到之結果依重要性給予不同之權重關係，最後再以 SPA 運
算推論後得知最短逃生路徑。
SPA 基本策略為考慮起始點與終點之間各段路徑所需花費之成本
(Costs)加總以求取最小成本(Minimum cost)。以圖 5 為例，陸路上之[x]中
之 x 值代表行進此子路段所需花費之成本，以 A－＞G 點為例，其中經過
各段成本並不相同，如圖 6 所示，分析後可以得到 11 種不同之路徑[28]。

[10]
B E
[16] [12]
[3] [12]
[14] [20]
A C G

[5] [15] [4]

[8] F
D
[17]
圖 5：最短路徑演算法

P ath C ost

[15] [4]
F G 38
[20]
G 39
[3] [12] [12]
C E G 43
[16] [10] [12]
B E G 38
[12] [12]
E G 38
[14] [20]
A C G 34
[15] [4]
F G * 27
[8] [17] [4]
D F G 29
[5] [12] [12]
C E G 37
[20]
G 33
[15] [4]
F G 32

圖 6：所有可能路徑

使用者目前位置(A)到避難所(G)，共有 11 條可達路徑，12 段構成各

路徑的子路段，分別算出各子路段之成本後，便能求出路徑的總成本。由
A 至 G，得知 A－＞C－＞F－＞G 其成本最低，表示此路徑為使用者(A)
到避難所(G)之適合路徑，再與其它避難所之路徑比較挑出成本最小的路
徑，此為 RSDS 中所建議之最適路徑(Adaptive Path)，接著以 VR 方式展
示，讓使用者能撤離災區並逃生至避難所。
四、系統架構與方法
4.1 系統架構設計
使用者單純地透過桌上型電腦在網路上進行視覺化(Visualization)的
應用，但目前已不能滿足使用者的需求，使用者逐漸轉變為希望在任何時
間或地點都可以接收到多媒體相關資訊。本計畫規劃設計與製作出一情境
感測式即時災害通報系統，其包含以下三部份(1) 可行之跨異質環境整合
式行動式使用者端(Integrated Mobile Users over Heterogeneous Networks
and Devices)環境，(2) 設計與製作出一具智慧型代理人機制之多媒體應用
伺服器(Multimedia Application Servers with Intelligent Agent Mechanism)，
以及 (3) 設 計 與 製 作 出 主 動 式 災 情 通 報 資 料 庫 系 統 (Active Database
System for Disasters Altering)。RSDS 採三層次(3-Tier)架構，系統架構如圖
7 所示，以下針對各單元分別敘述說明。

圖 7：情境感測式即時災害通報系統系統架構圖

4.1.1 可行之跨異質環境整合式行動式使用者端(Integrated
Mobile Users over Heterogeneous Networks and Devices)
使用者可利用各種終端設備進行災情通報與存取系統資料，其中包括
個人電腦((Personal Computer, PC)、筆記型電腦(Laptop)、智慧型手機
(Smart Phone)、平板電腦(Tablet PC)與個人數位助理器(PDA)等相關之手
持式設備(Handheld Devices)，使用者可透過任—設備與行動通訊網路或網
際網路與 RSDS 進行連線。此計畫將預定與設計之行動式使用者端功能包
括 (1) 基 礎 座 標 服 務 (Location-Based Services) 、 (2) 客 製 化 資 訊 服 務
(Customized Information Services)與跨異質網路傳輸(Over Heterogeneous
Networks)與(3) 即時多媒體傳輸(Real-time Multimedia Transmission)，相關
策略與方法，論述如下。

1. 基礎座標服務(Location-Based Service)之設計
行動式使用者利用手邊的終端設備連結至行動通訊網路或網際網
路，登入並使用 RSDS 系統，並藉由 GPS 自動進行所在地區定位。GPS
所得到之座標則利用 GSM/GPRS 手機經大哥大行動通訊網路傳回到後端
主動式災情通報資料庫中，進行地區資訊分析。此功能在儲存每一位使用
者位置，提供基礎座標服務，用以了解每一位使用者所在地區與所在地資
訊，再經由後端資料庫進行決策分析後匯整出一張表單，將所有線上使用
者列出，並可知道該使用者是否位於危險區域中。其主要原理是利用人造
衛星發射無線電波至地面接收器所需時間差計算太空衛星與使用者接收
器之距離，而定位測量的基本方式為人造衛星利用載波頻道以無線電信息
發送衛星位置與時間相關資料，GPS 接收器自接收 GPS 衛星傳送的訊號
後，經由接收器內的運算單元，解算出定位、速度、時間等使用者所需之
資訊。由於每顆衛星的位置可經由衛星星曆軌道資料求得，透過四顆以上
衛星至接收器之距離，便可算出接收器在地球上經度、緯度及高程的三維
座標值。
本計畫預計將結合 GPS 與個人數位助理器(Personal Digital Assistant,
PDA)，是希望在不受時空限制下幫助使用者定位，使用者透過衛星能得
知所在地之位置座標數據，其運作方式如圖 8。使用者所使用 GPS 接收器
模組與 PDA 結合連上 GPS 系統後，會尋找在附近上空之衛星，僅需 4 顆
就能精密的定位使用者位置(3 顆定位座標，1 顆定位高度)，利用差分定
位(Differential GPS, DGPS)之相對技術將移動中的 PDA 進行定位。方法是
一部已知座標 的固定儀器，與未知座標 的 PDA 端進行同步觀測，計算
兩點間的座標差，視其為改正值，從基站傳送到移動站(GPS 接收器)，GPS
接收器之瞬間觀測量加上改正值，便可計算出高精度之使用端座標，並顯
示在 PDA 上。

衛星2 衛星3

衛星1 衛星4

基站改正值

基站 GPS接收器

圖 8：GPS 運作定位方式
 在所設計的研究方法中，所可能遇到之問題為 GPS 接收器(使用者單
元)因天氣關係接收不良，無法進行使用者座標之定位，如此之情形無法
得知使用者之所在位置，系統無法自動給予相對之資訊。因此在此設計，
亦可利用手動式定位之模式進行使用者坐標位置之定位，使用者點選所位
於之縣/市與鄉鎮等資訊，輔助定位與存取資訊。其運作方式為用戶端
(PDA)利用手機提供的 GPRS 網路把想要查詢的地理資料透過基地台傳到
GPRS/WAP 閘道伺服器，GPRS/WAP 閘道伺服器把無線網路資料轉換成
有線的格式傳到網際網路再送到伺服器上，伺服器根據使用者的要求從
GIS 資料庫內把相關的資料擷取出來傳回給使用者。
GPS 接 收 器 大 多 由 美 國 國 家 海 洋 電 子 學 會 (National Marine
Electronics Association, NMEA)制定其規格模式，目前以 NMEA-0183 最為
廣泛使用，其傳輸的資料採 ASCII 的編碼格式，並以「句子」的方式傳
輸資料，每一個句子以「$」為起始位置，而以 16 進位控制碼「13」 、
「10」
為終止，句中的欄位（Field）以逗號「,」隔開。NMEA 常用到的數據格
式有以下幾種：
(1) GPGGA(Global Positioning System Fix Data)
z GPS 接收器所接收到之定位資料為
z “$GPGGA,172138,2504.2864,N,12129.7098,E,1,07,99.9,99999.
9,M,9999.9,M,,*73”
其每部份所代表之意思如下
z 172138：接收的時間(世界標準時)，格式為時分秒
z 2504.2864：緯度，格式：度分.分
z N：北半球(S 則指南半球)
z 12129.7098：經度，格式：度分.分
z E：東半球(W 則指西半球)
z 1：GPS 等級，0(無定位功能)；1(非差分定位)；2(差分定位)
z 07：所使用之衛星數
z 99.9：平面精度指標(HDOP)
z 99999.9：天線高度(平均海水面)
z M：單位(公尺)
z 9999.9：地表高度
z M：單位(公尺)
z *73：(換行)
(2) GPS 建議最小傳輸資料(RECOMMEND Minimum SpecificGPS,
GPRMC)
z GPS 接收器所接收到之定位資料為
z “$GPRMC,172138,A,2504.2864,N,12129.7098,E,1851.8,038.2,1
20101,003.4,W*62”
其每部份所代表之意思如下
z 172138：接收的時間(世界標準時)，格式：時分秒
z A：接收儀狀態，A：正常接收；V：接收儀警告
 z 2504.2864：緯度，格式：度分.分
z N：北半球(S 則指南半球)
z 12129.7098：經度，格式：度分.分
z E：東半球(W 則指西半球)
z 1851.8：速度，節(knot)
z 038.2：航徑，度
z 120101：接收之日期(世界標準時)格式：日月年
z 003.4：磁方位角 0~180 度
z W：磁方位角(西 W 或東 E)
z *62：(換行)
在 NMEA 規格裡的 GPGGA 及 GPRMC 數據裡都有記載著使用者利
用 GPS 接收器所擷取到的訊號，如此依接收到的訊號去解析 GPGGA 與
GPRMC 的資料，因此要取得 GPGGA、GPRMC 裡經緯度、時間、日期、
衛星數的資料，則是依 GPS 的語法逐一抓取直到我們需要的值為止，而
GPGGA、GPRMC 都有記載經緯度與時間的資料，因此從兩部分所取出
的值作對照以增加其準確性，如此獲得此坐標後便可進行使用者位置之判
斷，將資訊傳送給使用者。
此計畫所設計之情境感測式即時災害通報系統建置需先將歷史災害
資訊及相關資料建檔，其資料取得對於即時災害預警將扮演重要角色，而
全球衛星定位系統(Global Position System, GPS)[5][13]則是目前大面積野
外空間資料收集之最佳工具。GPS 的系統架構一般可分為太空單元(Space
Segment)，控制單元(Control Segment)及使用者單元 (User Segment)等三
部份，其中太空單元及控制單元屬於衛星發射單位掌管控制，使用者單元
將涉及資料接收精度及時效，為一般使用者所關切。使用者單元所指的是
能夠接收 GPS 衛星訊號之接收器。另配合地理資訊系統作為本作業系統
結合空間及屬性資料之另一工具，並提供各地理空間之分佈資訊，進而執
行資料之儲存、處理與分析，而 GPS 則可快速精確的提供各地區之構造
物之地理座標位置，因此整合 GPS/GIS 此兩種科技將可快速正確的提供
受災區之災害相關資訊[5]。
在所設計的研究方法中，所可能遇到之問題為 GPS 接收器(使用者單
元)因天氣關係接收不良，無法進行使用者座標之定位，如此之情形無法
得知使用者之所在位置，系統無法自動給予相對之資運。因此在此設計，
亦可利用手動式定位之模式進行使用者坐標位置之定位，使用者點選所位
於之縣/市與鄉鎮等資訊，輔助定位與存取資訊。
GIS 在 RSDS 系統中將結合 PDA，讓使用者能隨意地查詢 GIS 資料
庫中的相關地理資訊，其中包括三方面[15][21][22]：
(1) 自然環境：包括行政區域、地形、地貌、地質、氣象、水系、
流域、水文、土壤、植群分布等圖層資料。
(2) 人文環境：包括土地利用、採礦、伐木、開路、棄土、濫墾、
濫建、濫葬等人文活動。
(3) 災害環境：包括山崩、土石流、地滑、底土滲流、向源侵蝕、
 土壤侵蝕等潛在性災害。
其運作方式為用戶端(PDA)利用手機提供的 GPRS 網路把想要查詢的
地理資料透過基地台傳到 GPRS/WAP 閘道伺服器，GPRS/WAP 閘道伺服
器把無線網路資料轉換成有線的格式傳到網際網路再送到伺服器上，伺服
器根據使用者的要求從 GIS 資料庫內把相關的資料擷取出來傳回給使用
者。

2. 客製化資訊服務(Customized Information Service)與跨異質網路

傳輸功能(Over Heterogeneous Networks)之設計
RSDS 提供行動化使用者，能依據其使用之設備不同提供不同之介
面，進行最適當之連結，並依據使用者帳號與所在地之不同，提供使用者
所在地相關資訊同時提供客製化(Customized)相關服務，包括客製化介
面、客製化資訊、地理資訊、該地區是否有災害發生與新聞下載等資訊，
使用者不需再經繁瑣的步驟將相關資訊擷取下來，其控制訊號如下圖 9
所示，而控制訊號的設計步驟如下：
(1) 行動式使用者端發訊登入系統之訊息給與該區域之應用伺服
器。
(2) 應用伺服器收到訊息之後，向後端主動式資料庫發出要求客
製化資訊之訊息給智慧型代理人，並同時給予行動式使用者
相關之適性化介面。
(3) 智慧型代理人接收到由應用伺服器發出之訊息後發送檢索新
資訊之訊息並同時送出客製化資訊給與行動式使用者。
(4) 行動式使用者接收到客製化資訊並會接受相關之新資訊。

行動式使用者端 應用伺服器 智慧型代理人 主動式資料庫

登入系統
要求客製化資訊
給予適性化介面 檢索新資訊
客製化資訊
客製化資訊
相關之新資訊
相關之新資訊

圖 9：客製化資訊傳遞之訊息

此計畫所設計之使用者平臺為跨異質網路進行資料傳輸，因為使用者
所處之網路不同，因此系統之設計讓終端設備或行動設備可透由全球通訊
網路(Global System for Mobile Communications, GSM)、無線分封交換服務
(General Packet Radio Service, GPRS)、有線網路與 IEEE802.11b 無線網路
等環境進行整合使用，將使用者之資訊記載並透由主動式資料庫發出訊息
通知行動式使用者，而資訊傳遞則依網路與設備所擁有之狀態提供不同之
服務品質。
RSDS 系統因使用者所使用之終端設備不同而提出不同之介面與資
訊，因此在設計中我們將採用資訊金字塔之方式進行資訊之分配(如圖
10)。若使用較好之設備，並具備較大頻寬時可要求傳輸較豐富之資訊，
圖所示為資訊金字塔。若情況許可，可傳送全文資訊、8 位元圖片與 1M
之影音與 50kbps 之語音，若最差時僅送出重要之資訊通知使用者。

圖 10：資訊金字塔

3. 即時多媒體傳輸(Real-time Multimedia Transmission)之設計

即時多媒體傳輸部份包含文字(Text)、圖片(Picture)與影音(Video and
Audio)三部份進行資料的傳輸，使用者可以利用一般文字進行線上交談並
將 訊 息 群 播 (Multicast) 傳 送 給 位 於 同 一 區 域 的 群 組 所 有 成 員 (Group
Members)。在本系統中，建立一群體廣播聊天室(Multicast Chat Room,
MCR)，輔助資訊即時之傳遞，提供位於同一區域中之成員(Member)能進
行即時文字互相交談並傳輸相關之訊息，如此位於同一群體(Group)之成
員能迅速獲得最即時之文字訊息。此外亦可利用 PDA 上的照像機將災區
第一現場現地情況拍攝下來，即時地傳送回防災中心給予專業人員進行研
判，或利用影音傳送之功能將現場影音傳送回位於防災中心之專業人員，
以利相關第一手災情之研判。

4.1.2 具智慧型代理人之多媒體應用伺服器(Multimedia
Application Servers with Intelligent Agent Mechanism)
位於網際網路前端之多媒體應用伺服器主要在於建構出提供虛擬實
境(VR)、多媒體(Multimedia)環境、感測網路(Sensor Networks)、Web
Service、與 HTTP 串流服務之服務環境，其主要目的在分離巨量之多媒體
資訊以節省後端資料庫存取資料之時間。此外亦提供許多智慧型資訊代理
人(Intelligent Information Agent)進行資料的蒐集、搜尋、分類、處理或通
報等工作，能迅速確實地讓使用者掌握最即時資訊。所設計功能主要包括
(1) 智慧型資訊代理人、(2) 災情視訊監控、(3) 災情影像管理、(4) 感測
網路閘道器、(5) 工程虛擬實境展示以及 (6) HTTP 多媒體串流服務等相
關功能模組。
其中多媒體之機制為利用視覺化網路技術(Visual Network Techniques)
為核心機制，除提供多媒體串流影音外，另以 3D 虛擬實境技術整合感測
網路(Sensor Networks)進行防災工程情境模擬，以改善防災工程實施的作
業流程及設計。此外亦同時利用漫淹災情模擬，並結合感測網路之定位展
示，以瞭解當地真實情境，透過模擬飛行視點設定展示和場景編輯功能，
更能讓快速進行災情模擬與預防。

1. 智慧型資訊代理人
RSDS 所設計之智慧型代理人之主要功能，將網路上之資訊分門別類
分類與檢索，系統自動下載使用者所在地資訊同時提供客製化
(Customized)相關服務，包括依使用者端設備不同提供不同之畫面、所位
於地區即時災害與新聞下載等資訊，讓使用者不需經繁瑣的步驟將相關資
訊擷取下來，其目的在分離巨量之多媒體資訊以節省後端之資料庫存取資
料之時間，希望將災情通報技術發展成為一個自動化和資訊化之系統以針
對各代理人進行簡述說明。。
(1) 使用者介面代理人：依據使用者終端設備展示能力與其它資
源限制，主動調適系統展示操作模式，讓每一種操作平台皆
能獲得最佳的展示效果。
(2) 資源監控代理人：提供資源監控機制，負責監控網路頻寬與
客戶端之系統資源狀況，情境管理代理人將可依資源監控代
理人所監控取得之使用者設備資源或伺服器負載狀況進行服
務調適控制。
(3) 雨量資訊代理人：自動與中央氣象局提供之雨量資訊網站連
線，擷取即時雨量資訊，並隨時提供給各個使用者。
(4) 新聞資訊代理人：自行與特定新聞網站連線，依據關鍵字自
動抓取搜尋相關災情之新聞資料，讓用戶端能觀看最近所發
生的緊急事件。
(5) 緊急通報代理人：當災害發生時，本代理人將自動發出即時
災情通報，讓災區民眾能儘速疏散至安全處，以達到即時防
災、預警效果。
(6) 位置感知代理人：利用 GPS 連線至衛星抓取使用者目前所處
的地方，將其擷取並判斷，再將其轉換為平面座標，透過情
境管理代理人進行資料儲存與管理，以提供使用者更多個人
化的資訊。
(7) 協調代理人：依據各代理人所擷取資料進行協調分析動作，
將各代理人取回之資料利用分類樹功能進行資料分類，以避
免相同的資訊於伺服器重覆存取。
 (8) 感測網路監控代理人：主動收集感測網路各感測器(Sensor)資
訊，透過如位移、環境溫度、溼度及亮度等資料收集，傳回
專屬資料庫，以便讓災害研究專家分析研究。
(9) 情境管理代理人：提供標準化之使用者情境資訊處理程序，
其中所包含之情境解釋者(Context Interpreter)模組元件，透過
資源監控代理人、感測網路監控代理人與位置感知代理人等
感應偵測來源所收集之資料，進行情境識別、情境表述等任
務。而對於情境資訊之識別與表述，本計畫採用全球資訊協
會(World Wide Web Consortium, W3C)所制定之網站本體語言
(Web Ontology Language Overview, OWL)標準，並依據多媒體
串流服務應用領域之相關情境特性，進行定義設計情境資訊
本體詞彙(Context Ontology Vocabulary)，以供情境管理代理人
進行情境狀態的描述、分析與推論。

2. 災情視訊監控
為提供災害應變中心人員能快速觀察各災區災情狀況，進行即時性的
災區災情監控，本計畫將設計規劃災情視訊監控功能與災情視訊串流傳輸
服務，以下針對其所提供之各項子功能進行說明。
(1) 多方同步視訊展示：使用者可依其需求，由視訊展示框中選
擇欲觀看之視訊來源進行同步展示，其來源包含 WebCam、IP
Camera 等視訊擷取設備，提供災害防救人員隨時同步掌握所
有災情資訊。
(2) 視訊框頁調整服務：當使用者欲更清楚的檢視某視訊來源
時，經由滑鼠點擊其中一個視訊框頁，便能將其展示框頁放
大，以便進行更詳細的觀察監控。
(3) 串流品質調適服務：本功能可依據資源監控代理人所監控之
使用者情境資訊，進行平順之多媒體影音服務品質調適切
換，提供流暢之災情視訊串流服務。

3. 災情影像管理
本功能模組設計主要為提供災害歷史影像紀錄管理之用，並可提供相
關防救災人員未來做為災情預測參考之用，以下針對其所提供之各項子功
能進行說明。
(1) 災 情 影 像 擷 取 ： 行 動 式 使 用 者 端 可 在 災 區 現 場 使 用 IP
Camera、WebCam 或 O2 (Pocket PC)，進行災區現場情況拍攝，
再利用即時通訊程式將影像傳至主動式資料庫，作為土石流
專家判斷災情之參考依據，讓土石流專家能更快速了解當地
土石流發生之情形儘早研判，並告知是否需撤離。
(2) 災情影像管理：災情影像管理會將使用者所上傳之災區影像
依災情類別劃分並儲存於主機中，透過災情影像展示可瀏覽
目前或歷史影像訊息，以便將來查詢參考之用。
 4. 感測網路閘道器
主要近來由於微型製造的技術、通訊技術及電池技術的改進，促使微
小的感測器可具有感應、無線通訊及處理資訊的能力。此類感測器不但能
夠感應及偵測環境的目標物及改變，並且可處理收集到的數據，並將處理
過後的資料以無線傳輸的方式回傳。而感測網路閘道器則主要是接收各感
測器(Sensor)之訊號，並將 Sensor 所回傳的資料傳給 PC，做為感測器與
PC 之間資料傳輸之橋樑。

5. 工程虛擬實境展示
虛擬實境(VR)之設計是讓在現地探察的使用者，或位於遠處的專家能
在任何地點使用此功能查看各區域之相關防災工程施工模擬展示。VRML
程式語言產生之程式碼檔案較小，故有利於在 GPRS 上傳送相關之檔案與
模擬情況。針對較大或較精確的地形圖，運算繪圖仍極耗費系統資源，因
此利用 PDA 開啟較大的 VR 地形圖時，其所花費處理時間也相對地較長，
且不能像在 PC 端一樣的快速移動視點，有時甚至出現延遲展示之情形，
另外 PDA 螢幕展視解析度較低。基於以上理由此計畫將利用 ERDAS
IMAGINE8.5 軟體，將防災工程施工立體地形圖切割成多個小區塊，分割
同時也藉由該軟體將各區塊之地形解析度及格數調高，惟各區塊之經緯度
必需紀錄在後端的資料庫中，因此前端之 PDA 使用者利用 GPS 所取得當
地經緯度或輸入欲查看區域座標時，系統即會尋找該區域座落在哪個區塊
中，並直接呼叫出該區塊的 VR 地形檔，因為圖形較小且切割出之圖形精
緻度提高，此方式即可提供解析度高並且較不失真的立體地形給使用者參
考，故在 PDA 上能展示出較佳之效果與效能。
此計畫所設計之 VR 系統將架設在應用伺服器上，目標在使用戶端利
用手機提供的 GPRS 網路把把相關地區的地理圖片透過基地台傳到
GPRS/WAP 閘道伺服器，GPRS/WAP 閘道伺服器把無線網路資料轉換成
有線的格式傳到網際網路再送到伺服器上，VR 伺服器便能根據使用者所
預查詢之工程地點，模擬出現地的防災工程施工狀況，以供使用者進行查
詢瀏覽，其架構如圖 11。
透過虛擬實境(VR)的觀念與技術日益成熟，在防災工程施工方面如能
提供相關情境模擬，必能改善防災工程實施的作業流程及設計。因此在本
計 畫 將 利 用 SUN( 昇 陽 公 司 ) 所 提 供 之 Java 3D API 結 合 ERDAS
IMAGINE8.5 所繪制之真實比例立體圖層影像，實現於工程模擬之 3D 立
體影像展示設計。主要功能包含了漫淹災情模擬，並結合感測網路之定位
展示，以瞭解當地真實情境。此外更提供模擬飛行視點設定展示和場景編
輯功能，使本功能更能符合使用者需求。
行動電話
伺服端

網際網路

GPRS/WAP閘
基地台
道伺服器

PDA
VR資 料 庫
圖 11：由 PDA 存取 VR 資料庫

6. HTTP 影音串流服務
本計畫將於多媒體應用伺服器使用標準 HTTP 協定建置 HTTP 串流
服務，本服務可與災情視訊監控進行結合運用，主要為監聽並等待客戶端
連線要求，待使用者選取視訊來源後，系統會先將影像串流資訊傳輸至使
用標準 HTTP 協定建置的網路服務(Web Service)多媒體應用伺服器，透過
編碼器將龐大的多媒體資料壓縮編碼成適合於網路上傳輸之封包大小，以
提供穩定之串流服務。此外對於一般多媒體影音檔案之撥放，藉由接收由
客戶端傳送之連線要求與影片品質需求訊息，根據此訊息去媒體檔案資料
櫃尋找所要求之影片品質，並將最後找到之 MPEG-4 格式檔案傳送給使
用標準 HTTP 協定建置之串流伺服器，再透過編碼器主要負責將龐大的多
媒體資料壓縮編碼成適合於網路上傳輸之封包大小。目前串流技術大約可
分成如下表 1 兩大類，本計畫所採用之串流技術即為 HTTP 串流服務。

表 1：串流技術的主要種類
Web Server Streaming Server
(HTTP Streaming) (RTP Streaming)
不需要額外建置串流伺服器。 由於支援伺服器與客戶端互動，
因此可任意選擇檔案播放位置。
優點 傳輸層使用 TCP，品質較佳。
標準 HTTP 協定，無防火牆困
傳輸層使用 UDP，效能較佳。
擾。
由於 HTTP 之傳輸層使用 TCP 需要特別建置一串流媒體伺服
通訊協定，如果當網路頻寬出 器，建置比 Web Server 困難。
現擁塞造成資料遺失時，會造
缺點 成 大 量 資 料 重 傳 由於 UDP 缺乏資料回報遺失機
(Retransmission)，因此容易造 置，因此容易造成品質下降。
成延遲。 UDP 串流容易被防火牆阻擋。
4.1.3 設計與製作出主動式災情通報資料庫系統(Active Database
System for Disasters Altering)
位於網際網路後端之主動式災情通報資料庫系統主要包含災情資訊
資料庫、地理資訊資料庫、系統參數資料庫、情境資料庫與媒體檔案資料
櫃等資料儲存媒體，其運作模式為改良傳統的資料庫成為一個主動式資料
庫(Active Database)，主要採用 E-C-A(Event-Condition-Action)模型處理資
料，讓所有的資訊不再被動查詢，並且負責與 WinCE 資料庫進行同步之
工作，主動式資料庫將依使用者之情況主動通知使用者執行邊坡崩塌資料
查尋，因此當使用者一連上線時立刻詢問是否要輸入邊坡崩塌資料，若有
新的邊坡崩塌災情訊息亦會快速通知使用者，不需讓使用者自己下查詢語
法(Query Language)，進而影響邊坡崩塌災情通報時間。此外當使用者查
詢附近地域之邊坡崩塌資料，而一旦發現使用者正位在危險區時，則此系
統將立刻以警訊的方式通知使用者，查詢亦由被動轉成主動的方式，以達
到最高的成效與承擔最小之災害風險。主動式資料庫包含如媒體檔案資料
櫃、災情資訊資料庫、地理資訊資料庫與系統參數資料庫等元件，提供整
合性之災情資料儲存管控媒體，對災害監測與預測提供可靠資訊，為現階
段防救災系統ㄧ大重要輔助工具。
(1) 其中資料庫建置，無法採用單一技術解決全部問題，故利用
遙測技術(RS)、地理資訊系統(GIS)、全球衛星定位系統(GPS)
與衛星影像處理分析系統(IPS)等相關科技，整合建置邊坡崩
塌防治技術與 GPS/GIS/IPS 科技之串聯應用，進一步積極發
展邊坡崩塌防治技術自動化和資訊化系統，對於後續水土資
源保育利用和邊坡崩塌災害防治，均可提供精確快速之資訊
交流互通，實有益於邊坡崩塌災害環境資料庫作業系統之建
構。

4.2 方法設計
4.2.1 虛擬實境漫淹模擬
當發生豪大雨造成的水災可能將原本的道路，甚至原本到逃難所之最
適逃生路徑給淹沒住，造成救援逃生上的困難，故本計畫提出漫淹模擬的
方式來解決這方面的問題。透過感測網路監控代理人與兩量代理人，即時
地收集災區的資訊，並藉由地理資訊代理人將相關資訊，如經緯度座標及
海拔高度，進行運算產生漫淹範圍，以提供給使用者參考與決策，並讓最
適逃生路徑可以避開災害範圍，安全到達避難所。
在本計畫採用標尺設計方式[36]，以虛擬點位資料進行分析，並結合
網格資料運算的功能，如圖 12 為屏東科技大學之數位高程(DTM)資料，
透過使用凸殼演算法(Convex Hull Algorithm, CH)和空間內插方法(Spatial
Interpolation Methods, SI)得到的圖層與地形圖層運算，再去除無效的區
域，以獲得淹水深度的推估結果。
 圖 12：網格式呈現屏東科技大學 DTM 資料圖

1. 凸殼演算法(Convex Hull Algorithm, CH)

根據使用者所在之地理位置，連結至資料庫伺服器取得周遭之地理資
訊，再依不規則三角網格特徵點之數位高程進行漫淹之判斷，將被淹沒的
點載入至 CH 進行運算，如表 2 所示，以快速地產生概略的漫淹範圍。

表 2：凸殼演算法(Convex Hull Algorithm)

(1) Get input, N = number of points.
(2) Initialize: HullList, EdgeList, PointList.
(3) Choose two points, A and B, that form an edge.
(4) Choose any point C, not collinear with A and B.
(5) Compute cross product NX = (A - B) * (C - B).
X = the plane at B with normal NX.
(6) For every data point (except A, B, C) compute signed distance to plane
distance(P, X) = (P - B) * NX
and find the point, P, with maximum distance.
(7) If distance(P, X) > 0, then C = P and GoTo (6).
Else we know X is a face plane.
(8) Create a face, F, with all data points on the plane X. (This will include A,
B, C and possibly others).
(9) Sort F points according to angle(P) = (P - B) * (A - B)
(10) Add F to HullList.
(11) For each edge, E = (P1, P2), clockwise on the perimeter of F do {
ER = (P2, P1).
If ER is in the EdgeList list {
If E is in the PointList, remove E from the PointList.
}
Else {
Add E to the EdgeList
Add ER to the PointList
}
}
(12) If the PointList is empty, return the EdgeList and HullList.
(13) Else get (A, B) the next edge in the PointList and GoTo (5).
 2. 空間內插分析(Spatial Interpolation Methods, SI)
根據使用者區域，連結至資料庫伺服器取得周遭之地理資訊，再依不
規則三角網格特徵點之經緯度座標和數位高程，運用 SI 計算出該區域每
個位置之數位高程，再進行漫淹判斷，以產生精確之淹水區域，提供防災
人員決策參考用，空間內插分析(spatial interpolation)之設計如圖 13 所示：

圖 13：空間內插分析示意圖

(1) 作法：
I. 設置欲求取之內插點 P4 < X4 , Y4 , Z4 >
II. 取得內插點所屬三角網格區域特徵點，分別為 P1 < X1 , Y1 , Z1
>、P2 < X2 , Y2 , Z2 >、P3 < X3 , Y3 , Z3 >
III. 連結直線 P1P4 切直線 P2P3 於 P5 點
IV. 透過已知 P2、P3 兩點之數位高程，運用本計畫所提出之線性
距離加權法(the Linear Distance Weighted approach, LDW)計算
P5 點之數位高程：
Z5 = Z2 – ( Z2 – Z3 ) * d2,5 / ( d2,5 + d3,5 )
V. 透過已知 P1、P5 兩點之數位高程，運用線性距離加權法(LDW)
計算即可取得 P4 點之數位高程：
Z4 = Z1 – ( Z1 – Z5 ) * d1,4 / ( d1,4 + d5,4 )
其中：
z P1、P2、P3、P4、P5 為空間內之座標點，其中 P1、P2、P3 為
三角網格特徵點為已知數據，且 P1、P4、P5 及 P2、P3、P5 共
線
z X1、X2、X3、X4、X5 分別為 P1、P2、P3、P4、P5 之經度(已轉
換直角座標)
z Y1、Y2、Y3、Y4、Y5 分別為 P1、P2、P3、P4、P5 之緯度(已轉
換直角座標)
z Z1、Z2、Z3、Z4、Z5 分別為 P1、P2、P3、P4、P5 之數位高程，
表 3 為演算法內容
表 3：線性距離加權(the Linear Distance Weighted approach, LDW)演算法
Point P1 ,P2 ,P3 ,P4 ,P5 ; //Point 的結構有 X,Y,Z 分別代表經度、緯度、
高程
Line L1 ,L2 ; //直線方程式表示式 Y=aX+b，Line 的結構有 a,b 分別代
表 X 係數和常數項
L1 = LineFunction (P1 , P4 ) ;
L2 = LineFunction (P2 , P3 ) ;
P5 = substitutionElimination ( L1 , L2 ) ;
LDW (P5 , P2 , P3 ) ;
LDW (P4 , P1 , P5 ) ;
/**
* 計算兩點之直線方程式
* @param tempP1 , tempP2 傳入直線上兩座標點
* @return tempL 回傳直線方程式
*/
Line LineFunction ( Point tempP1 , Point tempP2 ){
Line tempL ;
tempL.a = ( tempP1.Y - tempP2.Y ) / (tempP1.X - tempP2.X) ;
tempL.b = tempP1.Y - a * tempP1.X ;
return tempL ;
}
/**
* 計算兩直線之交點
* @param tempL1 , tempL2 傳入兩直線方程式
* @return tempP 回傳相交點
*/
Point substitutionElimination (Line tempL1 , Line tempL2 ){
Point tempP ;
tempP.X = ( tempP2.b – tempP1.b ) / (tempP1.a - tempP2.a) ;
 tempP.Y = tempL1.a * tempP.X + tempL1.b ;
return tempP ;
}
/**
* 運用線性距離加權法計算插入點高程
* @param insertP 傳入插入點
* @param tempP1 , tempP2 傳入直線上前後之兩點
*/
void LDW (Point insertP , Point tempP1 , Point tempP2 ){
double distance1 , distance2 ;
distance1 = Sqrt( Exp( insertP.X - tempP1.X , 2 ) + Exp( insertP.Y -
tempP1.Y , 2 ) ) ;
distance2 = Sqrt( Exp( insertP.X – tempP2.X , 2 ) + Exp( insertP.Y –
tempP2.Y , 2 ) ) ;
30-a*(30-h)/(a+b)
insertP.Z = tempP1.Z
- ( tempP1.Z - tempP2.Z ) * distance1 / ( distance1 +
distance2 ) ;
}

(2) 驗證：
於圖 13 中作一過點 P4 且平行於直線 P2P3 之直線，設此直線切直
線 P1P2 於點 P6 且切直線 P1P3 於點 P7，如圖 14 所示。

圖 14：空間內插分析驗證示意圖
 ∵ 直線 P2P3 // 直線 P6 P7
∴ 直線 P1P6：直線 P1P2 = 直線 P1P4：直線 P1P5 = 直線 P1P7：
直線 P1P3
P1P6 P1P4 P1P7 P1P6 P1P4 P1P7
=> = = 假設： = = = S1
P1P 2 P1P 5 P1P3 P1P 2 P1P 5 P1P3
∵ 直線 P2P3 // 直線 P6 P7
∴ 角 P1P6 P4 = 角 P1P2 P5
角 P1P4 P6 = 角 P1P5 P2 又 角 P6P1 P4 = 角 P2P1 P5 (共角)
∴ ΔP1 P6 P4 相似於 ΔP1P2 P5 (符合相似三角形 AAA 特性)
同理可證 ΔP1 P6 P7 相似於 ΔP1P2 P3
∴ 直線 P6 P4 ： 直線 P2 P5 = 直線 P4 P7 ： 直線 P5 P3
P6 P4 P4 P7 P6 P4 P4 P7
=> = 假設： = = S2
P2 P 5 P5 P3 P2 P 5 P5 P3
I. 原作法內容：由 Z2、Z3 先求出 Z5，再由 Z1、Z5 求出 Z4
Z4 = Z1 – { Z1 – [ Z2 – ( Z2 – Z3 ) *Z2 ] } * S1
= Z1 – ( Z1 – Z2 + Z2S2 – Z3S2 ) * S1
= Z1 – Z1S1 + Z2S1 – Z2S1S2 + Z3S1S2
II. 驗證內容：分別依比例由 Z1、Z2 求出 Z6 與 Z1、Z3 求出 Z7，
再由 Z6、Z7 反推 Z4，判斷是否相同
Z4 = [ Z1 – (Z1 – Z2) * S1 ] – { [ Z1 – ( Z1 – Z2 ) * S1 ] – [ Z1 – ( Z1 –
Z3 ) * S1 ] } * S2
= Z1 – Z1S1 + Z2S1 – ( Z1 – Z1S1 + Z2S1 – Z1 + Z1S1 – Z3S1 ) * S2
= Z1 – Z1S1 + Z2S1 – Z2S1S2 + Z3S1S2
III. 由 I.、II.可證，I. = II.

4.2.2 虛擬實境最適逃生路徑
使用者可以透過無線行動網路連結到位於網際網路後端之主動式資
料庫伺服器，以進行最適路徑(Adaptable Escape Path, AEP)之推論，而 AEP
的推論模組係利用最短路徑演算法(The-Shortest Path Algorithm, SPA)進行
推估[27][28]，如表 4 所示。並提供最短路徑和最平穩路徑兩種模式來計
算各路段之成本，以確實輔助災民依不同之情境進行逃生。

表 4：最短路徑演算法(The-Shortest Path Algorithm, SPA)

找出從頂點 S 到任一個可達的頂點的距離與最短路徑。在這個演算法
中，L 表示已標示頂點的集合，而標點頂點 A 的前置頂點必屬於 L。
步驟 1：(標記 S)
(a) 將 S 標記為 0，且 S 沒有任何前置頂點
(b) 令集合 L={S}且 k=0
步驟 2：(標記頂點)
repeat
步驟 2.1：(將標記+1)
將 k 改成 k+1
 步驟 2.2：(擴大標記範圍)
while L 包含一個標記為 k-1 的頂點 V，V 又與不在
L 中的頂點 W 相連
(a) 將 W 標記成 k
(b) 將 W 的前置頂點設成 V
(c) 將 W 加入 L
endwhile
until
步驟 3：(建立到一個頂點的最短路徑)
if 頂點 T 屬於 L
T 上的標記就是 S 到 T 的距離。從 S 到 T 的最短路
徑就是反向從 T 開始往前追蹤，分別是 T 的前置頂點，T 的前置頂點的前
置頂點，繼續下去直到回到 S
otherwise
沒有從 S 到 T 的路徑
endif

1. 最短路徑(The-Shortest Path)推演
當災害發生時防救災人員需於第一時間內趕到災害現場進行救災動
作，故本系統提供最短路徑，以利防救災人員快速完成救治工作。其中各
道路成本計算方式為將經緯度轉換成直角平面座標，結合數位高程運用歐
基里德(Euclidean Distance)公式進行三維度之距離計算，如公式(2)所示：
EDi= ( X i − X i −1 ) 2 + (Yi − Yi −1 ) 2 + ( Z i − Z i −1 ) 2 ……………………公式(2)
EDi：第 i 條子路段，為道路點 i 到 i-1 之距離
Xi、Xi-1：第 i 點和第 i-1 點之經度轉換後直角座標
Yi、Yi-1：第 i 點和第 i-1 點之緯度轉換後直角座標
Zi、Zi-1：第 i 點和第 i-1 點之數位高程，如圖 15

圖 15：兩點間平面距離及三維距離示意圖

再將距離予以標準化(Standardize)，令其經過標準化後使距離值都介於
0 和 100 間，如公式(3)：
EDi
子路段距離之成本 EDi = × 100 ………………...………..公式(3)
EDMax
 完成標準化後，運用 SPA 計算各可達路徑，並取得成本最小之可達路
徑即為所求：
n

Min ∑ ED ，n：共有 n 條子路段………………………………公式(4)

i =1
i

2. 最平穩路徑(Smooth Escape Path, SEP)推演

由於各道路之坡度、斜率並不一致，特別在山區內道路坡度之變化更
是顯而易見，以屏東科技大學之坡度序數圖為例(如圖 16)所示，故一般的
最短路徑並不一定適用於所有人，對於像殘障人士、老幼婦孺或行動不便
者等，則需要一條較平穩的路徑來進行逃生，以提高逃生之安全性。

圖 16：屏東科技大學之坡度序數圖

有鑑於此，本計畫設計提供一最平穩路徑，其各路段成本之計算如下：
(1) 計算兩點間之高度差
兩點間之高度差 ΔHi=Zi-Zi-1…………………………….…公式(5)
(2) 取得兩點間之三維度距離，如公式(2)所示
透過 ΔH 和進行運算，取得其斜率(slope)，並予以標準化，令其經
過標準化(Standardize)後使距離值都介於 0 和 100 間，作法如下：
ΔH i
EDi
子路段距離之成本 S i = ΔH i 2
× 100 ……………………..公式(6)
1− ( )
EDi
其中 Si：第 i 條子路段，為道路點 i 到 i-1 之坡度
完成標準化後，運用 SPA 計算各可達路徑，並取得成本最小之可
達路徑即為所求：
n

Min ∑ S ，n：共有 n 條子路段………………………………….公式(7)

i =1
i
4.2.3 情境資訊本體論建置
情境感測式即時災害通報系統為能提供使用者一標準化之情境資料
處理流程與服務，因此於後端之主動式災情通報資料庫系統設計一情境資
料作為所有情境資訊之儲存媒體，其中將依據本計畫所規劃設計之情境資
訊本體論儲存個別實體情境資訊、調適控制歷史記錄與相關情境推理模組
等，以供情境管理代理人內部相關功能模組進行查詢與調適控制參考，針
對情境資訊本體論建置本計畫將預定進行(1) 情境分類、(2) 多媒體串流
服務領域情境資訊分析與(3) 情境資訊本體建置等設計步驟，以下分別敘
述說明。

1. 情境分類(Context Classification)
依據情境資訊的取得方式與本體論的概念，本計畫將情境資訊區分類
為兩項主要類別，分別為實體情境資訊(Concrete Context Information)與抽
象情境資訊(Abstract Context Information)兩類，其範例分類方式如圖 17
所示，以下分別敘述說明。

Computing Context

Abstract
Worst Medium Best Context
Information

Memory Network Card CPU

Worst Worst Worst Concrete

Context
Medium Medium Medium Information
Best Best Best

圖 17：情境分類範例

(1) 實體情境資訊：代表可由相關感測設備與監控量測機制等相
關情境提供者，直接取得之較低層級的情境資訊，當取得未
經處理的資料(Raw Data)後，透過明確界限(Crisp Limits)與模
糊集合(Fuzzy Set)兩種方式進行實體情境資訊之特徵識別，即
可取得實體情境資訊為何，例如圖 17 中所示之網路卡流量、
處理器負載、記憶體使用率等資訊即為實體情境資訊，直接
透過相關系統資源監控機置，即可取得數據進行實體情境資
訊之辨識。
(2) 抽象情境資訊：無法直接由情境感測來源直接取得，其必需
透過相關實體情境資訊進行推論分析進行粹取，因此抽象情
境資訊即為較高層級之情境資訊，舉例說明，運算情境資訊
 之情境值必需藉由網路卡流量、處理器負載、記憶體使用率
等三項實體情境資訊進行表述，例如當記憶體使用率低、網
路卡流量低且處理器負載低的情況下，運算情境其狀態即為
良好，因此抽象情境資訊必需透過其所關連或包含之實體情
境資訊作為推論與表述之依據。

2. 多媒體串流服務領域情境資訊分析
為能提供一明確且標準化之多媒體串流服務相關情境資訊領域內容
架構定義，並建置一整合度較高之情境資訊分享平台，首先必需先針對多
媒體串流服務領域進行內容分析，以建立較為完整之情境資訊本體詞彙
(Context Ontology Vocabulary)，由於多媒體串流服務所涉及之情境資訊相
當廣泛，因此本計畫針對已設計之調適控制機置所關連之相關情境資訊進
行 歸 納 分 析 ， 整 理 出 網 路 狀 態 (Network Status) 、 串 流 服 務 (Streaming
Service)、運算情境(Computing Context)、伺服器狀態(Server Status)、客戶
端 狀 態 (Client Status) 、 個 人 偏 好 (Personal Preference) 、 環 境 資 訊
(Environment Information)等主要抽象情境資訊類別，針對各項類別以下分
別述之。
(1) Network Status：於多媒體影音串流服務中網路狀態情境因為
一重要調適控制指標，其中如 Masugi 學者提出，多媒體串流
品質調適服務中主要以傳輸層(Transport layer)的封包遺失率
(Packet Loss Rate)與傳輸延遲(Transmission Delay)為主要控制
影響因素。此外客戶端與伺服器端之網路介面卡(Network
Card)每秒所收送之封包數與可用頻寬(Available Bandwidth)亦
可作為網路狀態重要評估依據(Masugi, et al., 2005)，因此於網
路狀態類別中包含了封包遺失率、傳輸延遲與網路介面卡狀
態等實體情境資訊。
(2) Streaming Service：於串流服務情境類別中可細分為緩衝區使
用 率 (Buffer Usage Rate) 、 串 流 接 收 速 率 (Stream Receive
Rate)、播放品質(Presentation Quality)與播放大小(Presentation
Size)等實體情境訊，用以表述串流服務情境。
(3) Computing Context：運算情境於此主要針對相關實體設計之資
訊處理能力或相關資訊進行表述，該類別其下可細分為中央
處理器狀態(CPU)、記憶體狀態(Memory)、處理程序數目
(Process Number)、網路介面卡狀態與可用頻寬，運算情境資
訊可作為資源控制與多媒體串流品質調適控制之參考。
(4) Server Status：伺服器狀態情境資訊其中包含服務客戶端數量
(Number of Clients)與運算情境，用以描述伺服器之負載情
形，可提供負載平衡服務(Load Balance Service)決策依據。
(5) Client Status：客戶端狀態情境資訊由於可提供行動手持式設
備進行多媒體串流服務，因此該情境類別其下可分為展示螢
幕大小(Screen Size)、電力狀況(Battery)兩項實體情境資訊與
 運算情境、串流服務兩項抽象情境資訊，提供客戶端資源使
用狀況與限制描述。
(6) Personalize Preference：個人偏好情境類別其下細分為使用者
滿 意 度 (User Satisfaction) 、 串 流 品 質 需 求 (Quality
Requirement)、音量大小需求(Voice Level Requirement)、展示
大小需求(Presentation Size Requirement)等實體情境資訊。
(7) Environment：環境情境資訊包含亮度等級(Light Level)、噪音
等級(Noise Level)與座標定位(Location)等等，用以表述辨別使
用者週遭環境資訊。

3. 情境資訊本體建置
完成多媒體串流服務領域情境資訊分析後，即可進行本體論之建置，
依據分析後所得之詞彙類別、關連性與階層關係，即可透過 OWL 進行本
體論之建置，所建立之情境資訊本體論，其相關之架構如圖 18 所示，本
計畫主情境資訊本體論主要以“Class”、“Individual”、“equivalentClass”與
“subClassOf”等構詞進行建置，情境類別間主要以“subClassOf”進行關連建
立，提供類別層次結構，例如運算情境即為伺服器狀態情境之子類別，然
而於所有情境資訊中，亦有兩個類別相同的關連，此即以“equivalentClass”
進行宣告。例如網路狀態與運算情境兩者子類別之網路介面卡狀態為等價
類別，透過 OWL 本計畫透過本體論的概念，建構出有系統的多媒體串流
服務領域本體論定義。

Network Card

Available Bandwidth Transmission Delay

Buffer Allocation

Presentation Size Rate of Stream Network Status Packet Loss Rate

Streaming Service Buffer Usage Rate

Light Level

Available Bandwidth Context Environment

Client Status Information Information Location

Network Card
Screen Size
Noise Level

Battery
Presentation size Personal
User Satisfaction
Requirement Preference

Computing Context Server Status Vioce Level

Quality Requirement
Requirement

Memory CPU
subClassOf
equivalentClass
Process no Number of Client
Abstract Context Information
Concrete Context Information

圖 18：情境資訊本體論
4.2.4 情境表述推論機制(Context Representation Reasoning)
1. 情境表述推論機制設計
情境表述推論機制主要目的為提供抽象情境資訊識別推論之用，其情
境表述推論機制演算法流程如圖 19 所示，本計畫採用貝式分類法
(Bayesian Classification)進行情境狀態推論辨識，由於抽象情境資訊是由多
個實體情境資訊或其它抽象情境資訊來表示，因此於使用者選定欲判斷之
抽象情境資訊後首先必須由(i) 情境資訊本體詞彙中判斷該抽象情境資訊
組成之實體情境資訊因子為何，(ii) 取得相關實體情境資訊因子後，即可
透過情境資訊提供者向情境資料庫檢索查詢個別實體情境資訊因子相關
歷史記錄，並透過貝式分類法，評估分析該抽象情境資訊狀態為何。

情境表述推論機制

輸入欲表述之抽象情境資訊H

取得實際之情境資訊組合X
X = {x1, x2, … xi}

由情境資訊本體詞彙取得H 所包
含之各情境值(h1…hj)

分別求算X 各情境值xj之 P( xi | h j )

分別求算各情境值hj之 P(h j | X )
n
P(h j | X ) = ∏ P( xi | h j )P( h j )
i =1

取得最大機率之情境值

END

圖 19：情境表述推論機制演算法流程

推論過程中首先假設 hj 表示欲表述抽象情境資訊所包含之各種情境
值，而 X 為實際情境資訊組合，而 xi 則代表 X 所包含相關實體或抽象情
境資訊因子值，由上述參數設定，可利用 P(hj|X)來表示當情境組合為 X
時其欲表述抽象情境資訊之情境值為 hj 之機率為多少，透過欲表述抽象
情境資訊個別情境值所對應之 P(hj|X)求算，依據所得之機率大小進行抽
象情境資訊所屬情境值判斷，當 P(hj|X)計算取得機率越大時，則代表該 X
情境組合與該對應之情境值 hj 間的關連性越高，由貝式定理(Bayesian
Theorem)得知，P(hj|X)求算方式如公式(8)所示。
 P ( X | h j ) P (h j )
P (h j | X ) =
P( X ) ……………………………………….….公式(8)
X 實際之情境資訊組合
xi 為 X 所包含之各種實體或抽象情境因子值
hj 為欲表述抽象情境資訊所包含之各種情境值
由於抽象情境資訊情境值判斷是依據各個 P(hj|X)機率值大小進行
辨識，由於公式(8)其分母為 P(X)，因此可將各情境值所屬之 P(hj|X)機
率求算過程同乘 P(X)，以進行簡化的貝式定理假設，將公式(8)簡化如
公式(9)所示。
P (h j | X ) = P( X | h j ) P(h j ) ……………………………………….……公式(9)
然而 X 是由多個實體或抽象情境資訊因子值所組成，因此對於抽象
情境資訊之情境資訊因子組合型態相當複雜，導致可能無法由情境資訊資
料庫中取出與 X 實際情境資訊組合完全相等之情境歷史記錄，進而導致
無法計有效計算 P(hj|X)之值。本計畫係由情境資訊本體論之概念進行領
域描述，由於 X 所包含之情境資訊因子每個屬性都是條件獨立的
(Conditionally Independent)，且各因子值必需於同時段內同時發生才可成
立的情況下進行機率計算，因此對於 P(hj|X)機率值之計算，可以透過公
式(10)進行推估，公式中 xi 代表 X 所包含之實體或抽象情境資訊因子值，
由於情境資訊資料庫中對於 xi 與其欲表述抽象情境資訊情境值 hj 的關連
記錄較容易取得，因此本情境表述推論機制首先針對個別 P(xi|hj)機率進
行求算，待所有情境資訊因子值之 P(xi|hj)機率皆取得後，再進行 P(X | hj)
機率計算。
n
P ( X | h j ) = ∏ P ( xi | h j )
……………………………………..……..公式(10)
i =1

利用上述公式計算可以取得欲表述抽象情境資訊所含個別情境值 hj
之 P(X | hj)機率，因此可透過公式(11)進行 P(hj|X)機率之計算，如此即可
取得當情境資訊組合為 X，且表述之抽象情境資訊情境值為 hj 之機率為多
少，經過個別情境值所屬 P(hj|X)機率值計算，取其機率值最大者，即可
判斷欲表述之抽象情境資訊情境值為何。
n
P (h j | X ) = P( X | h j ) P(h j ) = ∏ P( xi | h j )P(h j ) ……………………..…公式(11)
i =1

2. 情境表述推論機制範例
假設欲推論表述之抽象情境資訊為“運算情境”，其所能表達之情境值
分別為“運算情境佳”、“運算情境中”與“運算情境劣”，而透過本計畫所設
計之情境資訊本體論，可得知其所包含之實體情境因子分別為中央處理器
狀態、記憶體狀態、處理程序數目、網路介面卡狀態與可用頻寬，假設目
前情境管理代理人所收集的實體情境因子值分別為處理器負載高、網路卡
流量高、記憶體使用率高之情境狀態，且情境資料庫中與“運算情境”相關
之情境歷史記錄有 10 筆，如表 5 所示，該情境可表述“運算情境佳”、 “運
算情境中”與“運算情境劣”等三種情境值。
 表 5：相關運算情境資訊歷史記錄範例
編號 情境值 情境因子值組合
1 運算情境佳 處理器負載低、記憶體使用率低、網路卡流量低
2 運算情境佳 處理器負載低、網路卡流量低
3 運算情境佳 處理器負載中、記憶體使用率低、網路卡流量低
4 運算情境中 處理器負載中、記憶體使用率低、網路卡流量中
5 運算情境中 處理器負載低、記憶體使用率高、網路卡流量高
6 運算情境中 處理器負載中、記憶體使用率中、網路卡流量高
7 運算情境中 處理器負載高、記憶體使用率中
8 運算情境劣 記憶體使用率高、網路卡流量高
9 運算情境劣 處理器負載高、記憶體使用率中、網路卡流量高
10 運算情境劣 處理器負載高、記憶體使用率高、網路卡流量高

由表 5 得知 P(“處理器負載高”|“運算情境佳”) × P(“網路卡流量高”|“運
算情境佳”) × P(“記憶體使用率高”|“運算情境佳”) × P(“運算情境佳”)其值為
(0/3 × 0/3 × 0/3) × 3/10 = 0，而 P(“處理器負載高”|“運算情境中”) × P(“網路卡
流量高”|“運算情境中”) × P(“記憶體使用率高”|“運算情境中”) × P(“運算情
境中”)其值為(1/4 × 1/4 × 2/4) × 4/10= 0.0125，最後 P(“處理器負載高”|“運算
情境劣”) × P(“網路卡流量高”|“運算情境劣”) × P(“記憶體使用率高”|“運算
情境劣”) × P(“運算情境劣”)其值為(2/3 × 2/3 × 3/3) × 3/10=0.1334，因此由上
述個別之情境值所求算之機率值得知，該實體情境因子所表述之抽象情境
資訊值為“運算情境劣”之機率最大，因此可將其歸類於“運算情境劣”中。

4.2.5 調適推論機制(Adaptation Reasoning Mechanism)

本計畫所設計之情境管理代理人提供調適對映控制者元件，用以負責
調適控制的觸發與調適規則對映兩項控制，當情境資訊發生變動時，系統
即會觸發請求服務調適，並透過情境調適對映機制進行推論，情境調適對
映機制之演算法流程如圖 20 所示，RSDS 系統所提供設計之調適推論機
制 (Adaptation Reasoning Mechanism) 主 包 含 條 例 式 調 適 規 則 推 理
(Rule-Based Adaptation Reasoning) 與 案 例 式 調 適 規 則 推 理 (Case-Based
Adaptation Reasoning)，依據調適控制目的與相關情境資訊內容，用以取
得最適之調適控制規則，以下針對兩項推論方式進行敘述說明。
1. 條例式調適規則推理
藉由情境資訊本體論與情境感知代理人所提供之相關情境資訊處理
與情境表述推論機制的運作，可以有效率的進行現實情境資訊之識別與表
述，由於較上層的抽象情境因子能夠被完整的定義描述，進而減化降低了
調適推論的困難度，於 RSDS 系統中使用者或系統開發者可以簡易的事先
定義相關調適控制規則，所有事先定義之條例規則主要存放於情境感知資
料庫中，調適對映控制者可透過相關規則進行調適觸發與調適規則對映，
表 6 即為條例式調適規則簡易的定義範例。

調適對映推論機制

取得相關實際情境資訊

查詢預先定義之條例式調適規則

否
取得調適規則 設定篩選門檻值k

是 正規化情境因子之情境值Ci
ContextValuei
Ci = ∀i ∈ case{1..i}
ContextValueMAX

歐基理德距離公式求算最為類似之情境記錄
( i C1old − i C1new ) 2 + ( i C2old − i C2new ) 2 + L + (i Ckold − i Cknew ) 2
EDi =
k

取得調適規則

儲存情境資訊與調適記錄

END

圖 20：調適對映機制演算法流程

表 6：條例式調適規則定義範例
Pre-defined Adaptation Rules
Quality of Network Status (best) ∪ Streaming Service (best) then
Services Transmits the streams with complete quality;
Network Status (medium) ∪ Streaming Service (medium) then
Transmits the streams with degraded quality;
Network Status (worst) ∪ Streaming Service (worst) then
Transmits the essential streams;

2. 案例式調適規則推理
當欲進行調適對映推論之實際情境資訊屬於複合性情境因子，亦即其
組成方式可能包含了多種抽象情境資訊或實體情境因子，由於其構成因子
較為複雜，可能導致無法於條例式調適規則推理所事先定義的調適控制規
則中取得相似之情境條件，以致於條例式調適規則推理可能無法適用，在
此本計畫利用案例式推論(Case-Based Reasoning)概念進行改良設計(Leak,
1995; David et al., 1998)，以提出符合實際需求之案例式調適規則推理演算
法，主要是透由歐基理德距離(Euclidean Distance, ED)來實現案例式推
理，可推估出最近似的過往案例供使用者進行制定相關決策之參考，案例
式調適規則推理機制流程如下例幾點所示。
(1) 使用者設定一篩選門檻值 k，依據實際情境資訊所含抽象或實
體等情境因子個數，由情境資料庫中篩選出至少有 k 個構成
情境因子為相同之情境記錄。
(2) 對於實際情境資訊與情境歷史記錄所組成之因子值，必需先
加以正規化，其正規化公式如公式(12)所示，其中 Ci 為正規化
後所得之情境值。
ContextValuei
Ci = ∀i ∈ case {1..i} ………………………………公式(12)
ContextValueMAX
(3) 當取出所有組成情因子為類似之情境記錄並完成正規化後，
即可透過歐基理德距離公式求算最為類似之情境記錄，然而
由於各情境記錄所組成之因子個數皆有所差異，因此對於歐
基理德距離公式本計畫對其進行小幅度修改，以符合案例式
調適規則推理之需求，其求算方式如公式(13)所示，式中僅考
慮相同情境因子，對於不同之組成情境因子並不加以考慮。
(i C1old −i C1new)2 +(i C2old −i C2new)2 + L+(i Ckold −i Cknew)2
EDi = ∀i ∈ Case {1..i} …公式(13)
k
EDi：實際情境與情境歷史記錄之求算差距值
k：實際情境與情境歷史記錄構成因子相同個數
Casei：個別類似之情境記錄
new
i Ck ：實際情境因子值
old
i Ck ：情境歷史記錄之構成情境因子值

(4) 透過上述流程處理即可取得實際情境與情境歷史記錄之差距
值最小之案例，並將該情境歷史記錄所對映之調適控制提供
使用者進行參考，該推論取得的情境對映調適控制命令無論
使用者接受或改採其它調適控制，情境管理代理人皆需將使
用者實際所採用之調適控制與實際情境資訊記錄於情境資料
庫中，以便往後進行推論之用，並有助於提高案例式調適規
則推理之準確性。
五、系統實作
在此章節中將依所提之研究方法與技術，展示情境感測式即時災害通
報系統(RSDS)系統實作成果，系統實作部分包括三部份說明：(1) 可行之
跨 異 質 環 境 整 合 式 行 動 式 使 用 者 端 (Integrated Mobile Users over
Heterogeneous Networks and Devices)、(2) 具智慧型代理人機制之多媒體
應 用 伺 服 器 (Multimedia Application Servers with Intelligent Agent
Mechanism)與(3) 主動式災情通報資料庫系統(Active Database System for
Disasters Altering)。

5.1 可 行 之 跨 異 質 環 境 整 合 式 行 動 式 使 用 者 端 (Integrated
Mobile Users over Heterogeneous Networks and Devices)
RSDS 系統中，行動式使用者端可達到(1) 現地多媒體警訊傳輸時，
並透過手機內建數位相機拍攝災區圖片或影片儲存後，僅需點選圖片即可
將圖片傳輸至智慧型代理伺服器端供防災專家進行災情研判。(2) 為提供
災害應變中心人員能快速觀察各災區災情狀況，本系統提供災情視訊監控
功能與災情視訊串流傳輸服務，使用者可依其需求，由視訊展示框中選擇
欲觀看之視訊來源進行同步展示，其來源包含 Web Cam、IP Camera 等視
訊擷取設備，提供災害防救人員隨時同步掌握所有災情資訊。

5.1.1 災情影像管理
使用者可在災區現場使用 IP Camera、Web Cam、O2 (Pocket PC)或手
機拍攝災情現況，再將所擷取之影像透過無線行動通訊網路傳輸至伺服器
儲存建檔，作為災情判斷之參考依據，此外並提供相關管理功能，進行歷
史影像訊息管理維護，相關畫面如圖 21 與圖 22 所示。

圖 21：PDA 現地圖片傳輸 圖 22：智慧型代理伺服器圖片接收

5.1.2 災情視訊監控
為提供災害應變中心人員能快速觀察各災區災情狀況，本系統提供災
情視訊監控功能與災情視訊串流傳輸服務，以下針對其所提供之各項子功
能進行說明。
1. 多方同步視訊展示：使用者可依其需求，由視訊展示框中選擇欲
觀看之視訊來源進行同步展示，其來源包含 Web Cam、IP Camera
等視訊擷取設備，提供災害防救人員隨時同步掌握所有災情資
訊，相關畫面如圖 23 與圖 24 所示。
2. 視訊框頁調整服務：當使用者欲更清楚的檢視某視訊來源時，經
由滑鼠點擊其中一個視訊框頁，便能將其展示框頁放大，以便進
行更詳細的觀察監控。如圖 25 所示。
3. 串流品質調適服務：本功能可依據資源監控代理人所監控之使用
者情境資訊，進行平順之多媒體影音服務品質調適切換，提供流
暢之災情視訊串流服務。
4. HTTP 串流服務：使用者選取視訊來源後，系統會先將影像串流
資訊傳輸至使用標準 HTTP 協定建置的網路服務(Web Service)多
媒體應用伺服器，透過編碼器將龐大的多媒體資料壓縮編碼成適
合於網路上傳輸之封包大小，以提供穩定之串流服務。

圖 23：PDA 多方視訊展示 圖 24：PC 多方視訊展示

圖 25：PC 視訊框放大後畫面
5.1.3 災情即時通報服務
當災害發生時，第一時間的災情通報是相當重要的，本系統透過無線
行動通訊網路的透通性與手持式設備的便捷性，提供災情即時通報服務，
並有效整合 Web GIS 技術，透過地形圖層套疊與定位區域展示。將有利
於相關防災人員快速了解各區域災情狀況，迅速地訂定應變決策與進行救
災資源指派分配。此外現場一線防救災人員亦可透過本功能即時取得災情
定位資訊與鄰近環境相關地理資訊，有助於提升防救災效率並使災害造成
的人員財產損失降至最低，圖 26、圖 27 為災情查詢畫面而圖 28 為災情
通報畫面。

圖 27：PDA 通報 圖 28：PDA 災情
圖 26：PC 通報資訊查詢畫面
資訊查詢 即時通報

5.2 具 智 慧 型 代 理 人 機 制 之 多 媒 體 應 用 伺 服 器 (Multimedia
Application Servers with Intelligent Agent Mechanism)
多媒體應用伺服器提供智慧型代理人進行資訊分類與整理，並配合
WEB/Application 之功能，讓使用者經由 WEB 或 Application 介面進行資
料的傳遞與查詢，以及提供虛擬實境(VR)地型模擬展示等功能。於多媒體
應用伺服器設計雨量監控機制，對中央氣象局雨量站進行雨量資訊之擷
取，且定時定期進行資料的更新動作，讓資料之重覆性減至最低，同時對
擷取之資料進行系統化之分析與研判，並存入地理資訊系統資料庫整合判
釋。對於感測網路中感測器(Sensor) 之資訊，可透過如位移、環境溫度、
溼度及亮度等資料收集後傳回專屬資料庫，以便讓災害防救專家分析研
究，輔助災情之研判。

5.2.1 智慧型資訊代理人
RSDS 所設計之智慧型資訊代理人功能主要著重於災情資訊及各種
地理資訊的自動蒐集、分類、分析等工作，希望將災情通報技術發展成為
一個自動化和資訊化之系統以針對各代理人進行簡述說明。
1. 雨量資訊代理人：自動與中央氣象局提供之雨量資訊網站連線，
擷取即時雨量資訊，如圖 29 所示。
2. 新聞資訊代理人：自行與特定新聞網站連線，依據關鍵字搜尋相
關災情之新聞資料。
 3. 資源監控代理人：提供資源監控機制，負責監控網路頻寬與客戶
端之系統資源狀況，可依使用者設備資源或伺服器負載狀況進行
服務調適控制，如圖 30 所示。
4. 位置感知代理人：利用 GPS 連線至衛星抓取使用者目前所處的地
方，將其擷取並判斷，再將其轉換為平面座標，存入資料庫中，
提供使用者更多個人化的資訊。
5. 感測網路監控代理人：主動收集感測網路各感測器(Sensor)資訊，
透過如位移、環境溫度、溼度及亮度等資料收集，傳回專屬資料
庫，以便讓災害研究專家分析研究，如圖 31、圖 32 所示。
6. 緊急通報代理人：當災害發生時，本代理人將自動發出即時災情
通報，讓災區民眾能儘速疏散至安全處，以達到即時防災、預警
效果。
7. 使用者介面代理人：依據使用者終端設備展示能力與其它資源限
制，主動調適系統展示操作模式，讓每一種操作平台皆能獲得最
佳的展示效果。
8. 協調代理人：依據各代理人所擷取資料進行協調分析動作，將各
代理人取回之資料利用分類樹功能進行資料分類，以避免相同的
資訊於伺服器重覆存取。

`
圖 29：PDA 即時雨量查詢 圖 30：PDA 資源監控

5.2.2 地理資訊查詢
地理資訊查詢主要目的是要讓一般民眾、災害應變中心人員或災害專
家快速檢索災區相關地理資訊，其中包括即時雨量資訊、新聞資訊、感測
網路資訊、災情通報資訊與使用者定位資訊等查詢功能，當中又可依據使
用者定位資訊提供了當地地理資訊查詢功能，可輔助位於現地之使用者快
速查詢其所在位置客製化地理資訊，相關地理資訊查詢服務畫面如圖 33
與圖 34 所示。
 圖 31：PDA 感測資訊查詢 圖 32：PC 感測資訊查詢

圖 33：PC 定位資訊查詢 圖 34：PDA 定位資訊查詢

5.2.3 工程虛擬實境展示功能
仰賴於虛擬實境(VR)的觀念與技術日益成熟，3D 立體影像更能讓使
用者具有臨場感效果，進而逐漸取代傳統文字模式的展示模式。趨於現今
高科技思維理念下，在防災工程施工方面如能提供相關情境模擬，必能改
善防災工程實施的作業流程及設計。因此在本專題實務上利用 SUN(昇陽
公司)所提供之 Java 3D API 實現於工程模擬之 3D 立體影像展示設計。主
要功能包含了生態工法模擬、漫淹災情模擬，並結合感測網路之定位展
示，以瞭解當地真實情境。此外更提供模擬飛行視點設定展示和場景編輯
功能，使本功能更能符合使用者需求，相關畫面如圖 35 與圖 36 所示。

5.2.4 多媒體群播會議室：
本功能可提供多人進行即時性的多媒體資訊交流，其包含群播檔案訊
息傳輸與影像即時互動等相關功能，有利於相關防災救難人員或民眾進行
即時性的災情資訊交流，提供災區現地全權的災情掌握，相關畫面如圖
37 與圖 38 所示。
 圖 35：生態工法模擬場景編輯 圖 36：PC 漫淹災情模擬

圖 37：PC 多媒體群播會議室 圖 38：PDA 多媒體群播會議室

5.3 主動式災情通報資料庫系統(Active Database System for

Disasters Altering)
主動式災情通報資料庫系統主要包括下列三個部分說明，(1) 漫淹模
擬與(2) 最適逃生路徑(3) 情境感知。

5.3.1 漫淹模擬
當災害發生時往往因資訊的不足，故無法取得災害的範圍，雖然洪水
的發生的影響因子複雜，但小區域中地形起伏的因素的確是一重要的因
子，故要能對小區域範圍獲得較理想的災情推估，需採用尺度較小之數值
網格，以精確的反應局部地區之淹水變化情形。漫淹模擬結果的正確性與
地表高程資料之精確度密切相關，再透過三角網格的運算即可推算出漫淹
區域。行動式使用者端可輸入其所在標尺之淹水高度，回報至位於網際網
路後端模式庫伺服器，並依其行動式設備之狀態選擇快速回應之「凸殼演
算法模式」或較精確計算之「空間內插分析模式」進行模擬分析，如圖
39 為 PDA 凸殼演算法及空間內插分析漫淹模擬結果。本系統擁有 3D 虛
擬實境展示功能，提供防救災人員及一般使用者從不同之觀視點，取得詳
細的漫淹災情。
 圖 39：凸殼演算法及空間內插分析漫淹模擬

5.3.2 最適路徑(Adaptable Escape Path, AEP)推演

當使用者登入系統後，後端伺服器會根據使用者座標值至 GIS 資料庫
中搜尋所在地的 VR 地圖，將所搜尋到之地圖傳回給使用者，並將使用者
位置定位於地圖上。使用者可依其個人情境選擇「最短路徑模式」或「最
平穩路徑模式」，以進行最適逃生路徑之推演，並會自動規避災害區域，
以安全地到達避難所，如圖 40 為 PDA 於凸殼演算法與空間內插分析漫淹
模擬下之最短路徑結果。本系統擁有 3D 虛擬實境展示功能，並提供視點
飛行模擬，可讓防救人員及一般使用者由空間鳥瞰整條最適逃生路徑的情
況，以確實達到安全地逃生，如圖 41 所示。

圖 40：漫淹模擬之最短逃生路徑

5.3.3 情境感知
本計畫所設計之適用於普及運算環境之情境感測式即時災害通報系
統，透過知識本體論概念，依據使用者應用層相關情境資訊，提供可調適
播放品質之情境感知多媒體影音串流服務。本章節將針對 RSDS 系統之情
境識別推論機制、情境表述推論機制、調適推論機制，進行系統實作，其
相關實作系統畫面如圖 42、圖 43、圖 44 與圖 45 所示。
 圖 41：3D 虛擬實境漫淹模擬之最適逃生路徑

圖 42：本體論詞彙定義實作畫面 圖 43：調適服務對象設定實作畫面

圖 44：情境表述規則設定實作畫面 圖 45：調適規則設定系統實作畫面
六、結論
本計畫設計可克服時空限制與障礙的情境感測式即時災害通報系統
(A Real-time Situation-Aware Disasters System, RSDS)。RSDS 系統將災情
資訊系統與行動化通訊環境緊密結合，搭配輕薄方便的無線行動即時通訊
設備，提供內容豐富且多采多姿的多媒體資訊，並設計友善客製化的使用
者操作介面進行資料的瀏覧與檢索。讓資訊能快速且方便的傳達到使用者
手上，有效地符合災區實地之狀況應用。RSDS 系統將有效達成：
1. 即時提供災區實況之災情影像資訊，利用嵌入式多媒體影音串流
之技術(Multimedia Streaming for Embedded Applications)，即時進
行災區之視訊監控，於災情發生的第一時間，能立刻將災區之現
況傳回災情應變中心，透過品質調適控制機制與 MPEG-J 的影像
壓縮技術進行影像傳送，克服無線通訊網路頻寬有限之限制性。
2. 當災難發生時，經使用者告知逃生避難系統，能即時得到安全的
逃生路徑，若發生預料外狀況(例如系統告知路徑已淹大水)，透
過漫淹模擬功能，系統會自動依現在之情境迅速再計算出另一條
安全路徑通報使用者。
3. 引進較先進之災情無線行動傳輸技術，使受災區能超越時空限
制，有效傳遞即時性災情現況影像與發出請求支援救災資訊，以
利災情之掌控與救災支援行動之執行。
4. 即時提供災區實況之災情影像資訊，利用嵌入式多媒體影音串流
之技術(Multimedia Streaming for Embedded Applications)，即時進
行災區之視訊監控，於災情發生的第一時間，能立刻將災區之現
況傳回災情應變中心。
5. 利用即時災情影像監控設備，當災害發生時，第一時間告知使用
者讓使用者能擁有更充裕的時間依現況做適當的反應，此外對於
災情應變中心相關救災人員，可藉由統籌性的災情資訊查詢，有
效進行救災資源指派分配。
在未來的研究中希望導入嵌入式多媒體影像辨識技術(Multimedia
Recognition Technology)，以逹到智慧型災情自動監控，並整合相關醫療
資訊系統，成為一重要完整的防救災系統。此外規劃此系統能成為提供平
時防救災演練的有利工具，輔導防救災教育之宣導訓練邁入現代化，建立
災情資訊即時通報與災區受難人員快速發出請求救援訊息傳輸系統，以強
化全民防救災意識。
七、參考文獻
[1] Anand R., Roy H.C., and Anupama M., “ConChat: A Context-Aware
Chat Program”, IEEE Pervasive Computing, pp.51-57, 2002.
[2] Bellavista P., Corradi A., and Stefanelli C., “The Ubiquitous Provisioning
of Internet Services to Portable Devices”, IEEE Pervisive Computing,
pp.81-86, 2002.
[3] Chen G., and Kotz D., “A Survey of Context-aware Mobile Computing
Research,” Dartmouth Computer Science Technical Report TR2000-381,
2000.
[4] Dey A.K., and Abowd G.D., “Towards a Better Understanding of Context
and Context- awareness,” CHI 2000 Workshop on The What, Who,
Where, When, Why and How of Context- awareness, ACM, pp. 1–6,
2000.
[5] Dorigo, M. Maniezzo, V. and Colorni, A.“Ant System: Optimization by a
Colony of Cooperating Agents,” IEEE TRANSACTION on SYSTEM,
MAN, AND CYBERNETICS-PART B:CYBERNETICS, Vol. 26, NO. 1,
FEBRCARY, 1996.
[6] Fensel D., “Ontologies: A Silver Bullet for Knowledge Management and
Electronic Commerce,” 2000.
[7] Frauenfelder M., “A Smarter Web,” Technology Review, 2001.
[8] Gomez-Perez A., and Corcho O., “Ontology Languages for the Semantic
Web,” IEEE INTELLIGENT SYSTEMS, pp. 54-60, 2002.
[9] Gradecki, J., “The Virtual Reality Construction Kit, ” John Wiley & Sons,
New York N.Y., 1994.
[10] Gruber T.R., “A Translation Approach to Portable Ontology
Specifications, Knowledge Acquisition,” pp.199-220, 1993.
[11] Gu T., Pung H.K., and Zhang D.Q., “A service-oriented middleware for
building context-aware services,” Journal of Network and Computer
Applications, Vol. 28, No. 1, pp. 1-18, 2005.
[12] Korpipää P., and Mäntyjärvi J., “An Ontology for Mobile Device
Sensor-Based Con text Awareness,” Proceedings on Context ‘03, LNAI
no. 2680, Springer-Verlag, pp. 451–459, 2003.
[13] Lin, Y.B. and Imrich, C.“Wireless and Mobile Network Architectures,”
Wiley, 2001.
[14] Masugi M., Takuma T., and Matsuda M., “QoS assessment of video
streams over IP networks based on monitoring transport and application
layer processes at user clients,” IEE Proceedings of Communications,
Vol.152, Issue 3, pp. 335-341, 2005.
[15] Mattern F., “Ubiquitous & Pervasive Computing: A Technolog-driven
Motivation”, 2002.
[16] Nwana, H.S. and Ndumu, D.T.“ZEUS: A Collaborative Agents Tool-Kit,
Autonomous Agents ’98,” Minneapolis/St. Paul, USA, 1997.
[17] Schilit B., and Theimer M., “Disseminating Active Map Information to
Mobile Hosts,” Proceedings of IEEE Network, vol. 8, issue 5, pp. 22-32,
1994.
[18] Wuermli O., Wrobel A., Cheung H.S., and Joller J.M., “Data Mining For
Ontology Building: Semantic Web Overview,” Diploma Thesis–Dep. of
Computer Science WS2002/2003, Nanyang Technological University,
2003.
[19] 史頌恩。2001。網路式虛擬實境建立系統於二維圖集再利用之初步研
究。國立交通大學土木工程研究所碩士論文。
[20] 何建曉，民 88，“全球衛星定位系統(GPS)簡介”，產業調查與技術，
第一二九期：76~81 頁。
[21] 何瑞光，2000，“邁向第三代行動通訊的關鍵-GPRS”，通訊雜誌，第
80~85 頁。
[22] 李永隆，2002，“深入 PDA 程式設計-無線網路、硬體控制、主從式
資料庫”，台北：文魁資訊股份有限公司。
[23] 周天穎，2001，“地理資訊系統理論與實務”，台北：儒林圖書有限公
司。
[24] 涂裕琦。2002。PDA 在地震後管線災損調查之應用與實作。國立台
北科技大學土木與防災學系研究所碩士論文。
[25] 陳伯綱、曾建超，2000，“整合 GPRS 與 Wireless LAN 資料網路之兩
階層式架構與通訊協定”，國立交通大學資訊工程研究所碩士論文。
[26] 陳尊明、林盈達，1999，“GPRS 如何整合 GSM 與 Internet”，通訊雜
誌，第 69~77 頁。
[27] 曾寶漢、姚明華、賈仲雍、陳炫蒼、賴勇誠、梁原誠，2001，“GSM
行動通信網路的無線分封數據服務：GPRS 系統介紹”，電信研究雙
月刊，第 31 卷.第一期：第 1~20 頁。
[28] 馮景如譯。2000。作業研究。台中：滄海書局，第七版，第九章，第
393-414 頁。
[29] 黃國瑜，2000，“精通 WAP 網頁設計實務”，台北：文魁資訊股份有
限公司。
[30] 楊竹星。2002。個人行動通訊系統。國立中山大學資訊工程學系研究
所碩士論文。
[31] 鄭光耀、王志嘉、趙曉楓，2000，“精通 WAP/WML”，台北：文魁資
訊股份有限公司。
[32] 鄭瑞光，1999，“SMS、HSCSD 與 GPRS 之應用”，通訊雜誌，第 61~65
頁。
[33] 賴柏諭，2000，“WAP 網站開發指南”，台北：知城數位科技股份有
限公司。
[34] 賴進貴、王慧勳。1996。數值等高線內插之比較研究。國立台灣大學
地理系地理學報，Vol. 21，第 83-94 頁。
[35] 戴國仰。2003。地方政府重大災害危機管理之研究—以華航大園空難
及桃芝風災為例。國立東華大學公共行政學系研究所碩士論文。
[36] 顏利玲。2001。淹水災情網際網路回報及災情推估系統之建置。國立
台灣大學地理環境資源研究所碩士論文。
[37] 龔旭陽、顧浩翔、劉燕燕、林靖祐、羅月伶 ，2002/9，“跨異質網路
之行動式多媒體即時互動系統”，2002 年台灣網際網路研討會，新竹
清華大學。
[38] 龔旭陽、顧浩翔、羅佳明、魏君竹、林正雄、蕭玉雯、蔡光榮，民
91，“視覺化災害警報網路之研究”，第一屆垚淼區域永續發展研討
會，頁 126-135 ，宜蘭技術學院。