行政院國家科學委員會專題研究計畫 成果報告
總計畫暨子計畫：災害地理資料倉儲系統之研究與建置(Ⅰ)
計畫類別： 整合型計畫 計畫編號： NSC91-2625-Z-009-004- 執行期間： 91 年 08 月 01 日至 92 年 07 月 31 日 執行單位： 國立交通大學資訊管理研究所 計畫主持人： 黎漢林 計畫參與人員： 傅昶瑞, 竺世駿, 黃雅琪 報告類型： 完整報告 處理方式： 本計畫可公開查詢 中 華 民 國 92 年 10 月 31 日目
錄
一、 計畫背景與目的...4 1.1 研究背景 ... 4 1.2 研究目的 ... 6 1.2.1 整合計畫目的 ...6 1.2.2 本子計畫目的 ...8 二、 國內外相關系統及文獻回顧...9 2.1 緊急醫療維護... 9 2.2 防災應變系統... 10 2.2.1 土石流災害通報及應變系統 ...10 2.2.2 九二一地震災後重建管理系統 ...112.2.3 美國聯邦危機管理處(Federal Emergency Management Agency, FEMA)..12
2.2.4 喬治亞理工學院結構物受損調查系統 ...13 2.2.5 E Team 救災管理系統 ...14 三、 整合系統架構 ...16 3.1 各子系統說明... 16 3.1.1 子計畫一：災害地理資料倉儲系統之研究與建置 ...17 3.1.2 子計畫二：應用 XML 建立災害資訊網路之標準交換語言 ...18 3.1.3 子計畫三：結合 PDA/GPS/GIS 建立即時災情資訊彙報系統之研究與建 置 ...18
3.1.6 災害彙整網站 ...19 3.2 系統運作模式... 20 四、 災害資料倉儲系統之系統需求...21 4.1 資料庫系統需求 ... 21 4.1.1 連結遠端資料庫 ...21 4.1.2 即時災害查報之資料 ...22 4.1.3 災害新聞之彙整資料 ...22 4.2 資料倉儲系統需求 ... 23 五、 資料庫結構設計...25 5.1 災害災情主要資料 ... 25 5.2 災情細節資料表 ... 27 5.3 災害災情延伸資料表... 29 5.4 空間描述資料表 ... 30 六、 災害資料倉儲系統設計 ...32 6.1 資料收集 ... 32 6.2 建立資料預儲 Cube... 32 6.3 內政部消防署之災害通報型態--以娜克莉颱風為例 ... 35 6.4 資料分析--使用 Excel 進行樞紐分析之範例 ... 35 七、 子系統連結應用--災害新聞彙整系統...37 7.1 系統特點 ... 37
7.2 系統架構 ... 38 7.3 使用案例說明... 40 7.4 資料關連說明... 41 7.5 後續研究及未來方向... 42 八、 附錄一 資料表欄位結構...43 A.1 災害災情主要資料表... 43 A.2 災情細節資料表 ... 45 A.3 災害災情延伸資料表... 48 A.4 行政劃分資料表 ... 50 A.5 空間描述資料表 ... 51 九、 附錄二 災害新聞彙整系統操作說明...53 B.1 系統設定... 53 B.2 擷取資料... 56 B.3 檢視資料... 57 十、 參考文獻...58
一、 計畫背景與目的
1.1 研究背景
台灣地區隨著都市化及工業化之進展，人與自然爭地的情況愈演愈 烈，在忽視永續發展與環境承載力的限制下，許多山坡地及洪泛平原的不 當開發與違建的佔用，使得災害的頻率與損失規模有逐年增加之趨勢。尤 其在都市地區，由於都市人口密度增加，災害所造成的嚴重性及損失也相 對的提高。民國 85 年賀伯颱風造成的災害，讓政府及民眾了解大自然反撲 的嚴重性。而民國 88 年 7、8 月間台灣中南部豪雨所引發的淹水，不僅造 成了鉅額的農業損失。更因排水不良，而導致多處人口聚集的都市化地區 的淹水，造成人民生命財產的損失。而民國 88 年的 921 集集地震也造成了 中部地區的嚴重災害。接續於民國 90 年 7、8 月間的桃芝颱風期間與中部 地區所造成的土石流，更對 921 集集地震災區造成了二次傷害。而於同年 9 月間納莉颱風也造成台灣北部地區水患成災，人民生命財產的損失無數。 環境災害如地震、洪水、土石流往往造成巨大的人命與財產損失。在 面對環境災害的威脅，及動輒數十億的經濟與人民生命財產損失以及無法 量化的自然環境破壞時，政府與人民不能再以消極的視環境災害是無法抗 拒的〝天災〞，而應以往災害管理的經驗與所累積的知識為鑑，積極的應用 空間性資訊的展現並整合先進的知識管理與網際網路技術，針對不同的災 害主題，建立其主題式災害知識管理的機制。同時，藉由資訊技術中各種 知識挖掘與萃取方法的發展，及專家研究群與現有防救災相關計畫的研究 成果的彙整，逐步建立各類型災害之主題式災害空間知識庫，以支援未來 所需之災害管理決策分析。 災害管理過程中，需要大量且即時性的資訊，提供政府相關部門及救災人員做正確的決策判斷，一般民眾及公民營企業也需要即時及正確的資 訊來判斷是否需要採取防災的應變措施。例如：氣象局所建立的地震速報 系統，可以在一分鐘之內，定出地震的震央、規模、及其震度的分布，可 提升地震救災人員的應變速率。此外，若能結合地震速報系統的資料與空 間性的資料，進一步者何快速分析模擬震災地區可能的傷亡規模的結果與 主題式災害知識庫中已有的地震救災應變知識庫，則能使決策者更有效的 調度派遣救災人員及分配相關資源。同時，也能依既定防救災體系與制度 作有效率的組織動員。並藉由此「整合性災害資訊網路」的規劃，解決目 前在災害資訊的傳播與應用上，因防救災相關單位在不同的資訊傳遞機制 及使用不同資料格式所造成的障礙。而整合資訊傳播的機制與資料格式， 以提升對環境災害的緊急管理、預防和回應。 由國外災害防治的相關文獻中得知，架構「災害資訊網路(Disaster Information Network)」並透過網際網路的發展，讓災害相關資訊的傳播 速度大幅提昇，使政府、企業及一般民眾均可透過網際網路取得所需的資 訊，是目前在災害防治及管理上最主要的研究課題之一。
1.2 研究目的
1.2.1
整合計畫目的 91 年度永續會在防救災資訊研究群之計畫要點如下： (1) 利用網際網路技術結合政府機構、媒體新聞建立災情資訊網，提供民眾 最新的災情資訊。 (2) 應用知識管理技術整合防災國家型科技計畫研究成果，提供政府、企 業、社區民眾對防災所需的相關資訊與知識。 (3) 利用防災計畫辦公室資訊組建立之網際網路地理資訊系統，提供政府及 媒體單位災害地點空間定位及查詢之功能。 因此本整合計畫所規劃之總目標為： 1. 設計災害地理資料倉儲系統 本子計畫之目標為整合國內分散在不同權責單位資料庫中的各種不同 災害資料。本研究將建立災害資料倉儲系統，與各單位資料庫建立連結， 每隔一段固定時間自動收集彙整這些災害資料。為了能提供空間查詢與一 般查詢交互索引的功能，各類災害相關資料也將盡可能加上空間屬性，一 併納入資料庫來管理。 2. 建立災害資訊網路之標準交換語言XML(eXtensible Markup Language)，是目前網際網路應用上非常熱門 的技術，由於其跨平台的特性，可以在各種作業系統及硬體間流通，如 MS-Windows、UNIX、Win-CE、Palm 等，且行政院研考會於民國 88 年頒定的 行政資訊系統電子閘門功能規範即規定：資訊系統間互連時之資料傳送的 方式及內容格式，其中紀錄編碼採用 XML 技術，其應用潛力非常雄厚。為 了能與國內行政資訊系統接軌，本計畫擬應用 XML 技術，建立防救災上游 資料提供單位資料交換的標準，以使不同層級的防救災單位可以利用各種 傳輸方式(有線、無線)將擁有一致標準的資料，傳播至彼此的電腦上(個人 電腦、PDA)，並使用這些資訊進行災害防救決策。
3. 結合 PDA/GPS/GIS 建立即時災情資訊彙報系統 研究利用數位助理機、全球定位系統及地理資訊系統規劃開發一本土 性、高效率及低價位之即時現場災情空間與屬性資訊蒐集作業系統，並結 合國科會防災計畫辦公室資訊組已建置之單機與網際網路地理資訊系統， 作災情資訊展示，來提供給政府及媒體單位作即時災害地點空間定位及查 詢之功能。 4. 建置災害新聞彙整系統 隨時收集各類線上災害相關新聞並加以分類歸檔，分類的依據來自新 聞標題或其內容所包含的關鍵字。新聞的摘要及檔案資訊將彙整至災害資 料倉儲並賦予空間資料屬性，以便於空間查詢。 5. 建置防救災知識管理查詢系統 使用知識管理的概念，將政府各災害防救業務主管機關，在過去及今 後各類災害防救之方法與經驗，做一有系統地整理和持續建檔。有利於各 單位在災害防救方面的教育訓練。各災害相關研究計畫之成果，也應透過 相同的機制分享研究的成果，藉此提供國內災害相關的研究最完整的參考 資料。民眾與各村里基層也可以透過這套系統得到及時的災情資訊，以及 災害相關知識。而且透過本系統也得以明確瞭解政府單位目前在災害防救 上的處理作法，進而在災害發生時，可以更有效地配合與提出意見。 6. 建置災情資訊網站 建立方便易用的網站，直接提供民眾及各政府機關災情資訊，同時將 各類災害相關資訊，也有系統地分類整理，讓民眾與各單位在使用上都能 輕鬆上手。網站資料即時提供最新災情快報、災害新聞、和政府救災措施 的宣導，逐漸建立公信力，以成為災害發生時聯繫中央與民眾的重要管道 。
1.2.2
本子計畫目的 雖然內政部消防署已有依中央災害防救會報之「災害防救基本計畫」 所設計的「中央防救(處理)災情傳遞資訊系統」，並已上線運作，但唯有資 料庫設計部分善尚待改善： (1) 未整合來自其他各災害權責單位的資料，如公路通阻資料。 (2) 資料庫中的「災情」資料表，未經良好的正規化設計，致資料新增、刪 除、更新作業不易有效管理。 (3) 現有災害資料格式不易適用於各單位不同的查報需求。 為了針對上述不足之處加以改善，且使我國防救災資訊系統能具備更 實用的功能，本計畫的目的如下： (1) 設計能整合其他單位資料庫的資料倉儲系統 (2) 以嚴謹的正規化步驟設計資料庫，減少產生錯誤的可能性。 (3) 彈性化的資料格式設計，方便其他單位共同使用。二、 國內外相關系統及文獻回顧
2.1 緊急醫療維護
目前國內防救災應變醫療體系已計畫 在特殊災難及醫療時利用 PDA 與資料庫連 線取得最新資料。例如在毒化災害傷患現場 救護時可以運用 PDA 及 GIS 來傳輸與取 得最新資料以便做好最適當的解毒及入院 準備。美國的高級救護員把 PDA 固定於大 腿部位，蹲在地上急救同時，可將病人資料 快速點選鍵入 PDA，再利用無線傳輸，在 病人到院之前，醫院裡的醫護人員可先了解 病情，為病患的入院作好準備。 國內的新光醫院在導入 M 化三個月後就感到實際效益尚難以量 化。醫師可用 PDA 掌握病患病歷資料，並直接在 PDA 開藥囑或醫囑。經 由上傳、下載動作，護理人員可將醫生所交代的繁瑣指令，明列成工作清 單。PDA 詳列作業細節有助提升病床周轉率。提高病床周轉率，就是要縮 短原病患辦理出院時間，讓下位病患能銜接時間進駐病房。使用 PDA 可減 低護理人員疏漏出院事宜的狀況，才不會耽誤了病患的治療，也造成了醫 院住院費用的損失。為了讓作業流程效率再提升，除了在 PDA 中增列處方升醫院整體的運作流程銜接，瞭解病患的最新狀況如檢驗結果。 http://www.auto.fcu.edu.tw/~bulletin/high/bio/news/02/2002-0203-0400.htm http://hs.mc.ntu.edu.tw/paper/14-06paper.htm http://www.skh.org.tw/plan/news/2002/MOELE.htm
2.2 防災應變系統
2.2.1 土石流災害通報及應變系統 行政院農業委員會水土保持局之土石流災害通報及應變計畫之目的及 在於規劃並建置土石流災害應變整合系統,以於應變中心開設時能夠快速獲 取資料,進行防救相關決策。當有土石流發生時相關單位會派遣人員到災區 勘查當地的受災狀況。每位人員都會配置利用行動電話或是衛星電話來無 線傳輸的掌上型電腦﹝PDA﹞，這掌上型電腦可以讓調查人員在最短的時 間內把已輸入的災害資料傳回災害應變中心並利用 GPS 和 PDA來讓調查人 員標示出準確的受災區域以方便災情評估及日後的重建工作。 行政院農業委員會水土保持局之土石流災害通報及應變系統之首頁2.2.2 九二一地震災後重建管理系統 本網站為台灣大學所建置的 Web GIS 系統，用以提供各級政府以及民 間團體、村里志工、學校教師等，可以透過網路查詢或上傳重建資料。該 網站使用 MapGuide 系統設計，應用的架構相當理想，可惜僅供九二一震災 災後重建使用，只有特定對象可以經由帳號密碼來使用本系統，其他類型 的災害在此系統也未能查詢得到，因此本系統和一般民眾的生活並未能緊 密接合，為其缺憾之處。 http://gis1.921erc.gov.tw 九二一地震災後重建管理系統首頁
2.2.3 美國聯邦危機管理處(Federal Emergency Management Agency, FEMA) 該網站提供多種類型的災害查詢，並提供災害地圖供民眾參考。所使 用的 GIS 並非可直接透過 Web 互動的系統，而僅僅是地圖的呈現。使用者 是透過 Web 間接使用該管理處所建置的 GIS，在災害的報導上已經可以達 到一定的需求。但由於無法直接以互動方式使用如 Web GIS 的功能，如地 圖平移縮放與圖層的切換等，在地理資訊的呈現上就顯得僵化許多，並不 比觀看一般圖檔有明顯較佳的效果。在查詢災害資料方面，也只提供關鍵 字尋找的功能，並不是一個理想的災害網站。 http://www.gismaps.fema.gov 美國聯邦危機管理處首頁
2.2.4 喬治亞理工學院結構物受損調查系統
喬治亞理工學院(Georgia Institute of Technology, GIT)教授 David Frost 的研究團隊開發的掌上型電腦軟體最初是為了讓研究人員迅速地評估被地 震損壞的結構物，以設計更耐震的結構物。此系統在 911 世貿爆炸案中被 用來記錄世貿中心鄰近結構物受損狀況。世貿中心周圍 10 個街郭的檢測作 業，把依照傳統檢測與記錄方式需要一個月時間的工作時數縮短到在四天 之內完成(Bacheldor,2002)。 在世貿案中使用的掌上型電腦 PQuake 系統，原本是由美國國家科學基 金 會 (National Science Foundation, NSF) 所 補 助 的 研 究 計 畫 成 果 (http://www.nyu.edu/icis/Recovery/prjct03.html)，其目的為了要在地震之後快 速蒐集結構物損壞資料。該系統包括：掌上型電腦與特製的資料記錄軟體、 記錄位置座標的 GPS、記錄影像資料的數位照相機、數位錄音裝置。記錄 的所有資料都上載到空間資料庫。可利用 GIS 系統呈現和分析這些資訊， 以決定受損的範圍和程度。 使用者從掌上型電腦螢幕上的選單點選描述結構物受損狀況，此資訊 與 GPS 座標連結。同時使用者利用數位照相機拍照，也與資料和位置連結。 每日現場作業完成後，所有的資訊上載到空間資料庫來檢閱，以便工作人 員規劃次日的評估作業。此系統讓使用者不需要利用紙筆來記錄描述資料 和 GPS 座標，再輸入電腦才能完成數位資料的建置。此系統將所有資訊同 步化，使得現場人員不至於漏失任何需要檢查的事項。該團隊將以該軟體 為基礎，開發類似的介面在風災、洪水等災害後使用。 http://www.gis.fcu.edu.tw/project/show.asp?id=455 http://www.nyu.edu/icis/Recovery/prjct03.html
E Team 之防災系統架構
2.2.5 E Team 救災管理系統
E Team 是一套瀏覽器介面(Web-based)的救災管理系統，由 E Team 公 司所研發而成的(E Team, Inc., 2002)。此系統容許設定不同安全等級的多階 登入，其功能包括
• 即時訊息發布(Instant messaging)
• 互動式地理資訊系統套疊(Interactive GIS mapping)
• 救災資源管理(Resource and asset management)
• 災難現場掌上型電腦無線傳輸(Wireless PDA for field operations)
• 支援災變指揮系統(Supports Incident Command System)
• 所有資訊的數位紀錄(Digital record of all information) 另外，相闖套裝系統可分為以下四大類：
1. E Team 政府機關版 - 鄉鎮、縣市、中央機關、災防單位聯合組織 2. E Team 企業版 - 民間企業、社區組織、重要公共設施
3. E Team 行動版 - 利用筆記型電腦和固網或無線網路連線
E Team 系統整體架構 以下是 E Team EverywareTM 掌上型電腦系統所提供之基本功能： 1. 事件報告(Incident Reports) 2. 檢查表單(Inspection Forms) 3. 任務命令(Job Orders) 4. 資源申請(Resource Requests) 5. 設施管理(Facility Management) 6. 現場稽核(Field Audits) 7. 聯絡報告(Contact Reports) 8. 資料更新(Updates) 9. 訊息傳遞(Messaging) 10. 警訊(Alerts) 11. 安全管理(Security) E Team EverywareTM整合之行動系統有：
1. 表格與報告(Forms and reports)
2. 含使用者註記之地圖(User annotated Maps) 3. 全球衛星定位(GPS location finding)
4. 含使用者註記之照片(User Annotated Photographs) 5. 語音訊息註記(Voice Message Annotation)
6. 平面圖(Floor Plans) 7. 感測器(Sensors)
8. 雷射測距(Laser Range Finding)
三、 整合系統架構
3.1 各子系統說明
本計畫包含一個災害資料倉儲、三個子系統，並設計一災害彙整網站， 以完成前述的目標，整體架構如圖 2-1 所示，說明如下： 本整合計畫之整體架構如下圖。各子計畫間的關係，是以子計畫一所 建立的災害資料倉儲系統為中心，其他子計畫則在資料輸出入方面，各佔 有其不可或缺的地位。 子計畫三和「災害新聞彙整系統」提供了兩種重要的即時災害資料來 源：勘災人員回報的現地即時災情資料和新聞媒體的即時報導資料，並將 資料轉換傳送到子計畫一所設計的資料倉儲系統。子計畫二和總計畫所建 立的「災情通報及防救災知識管理網站」則是將子計畫一所儲存的各類災 情資料，經由網站透過 Web 介面輸出呈現給各種不同的使用者。其中子計 畫二讓「災情通報及防救災知識管理網站」資料，得以讓其他單位的資訊 系統自動轉換使用，更增加了本整合系統的使用效益。3.1.1 子計畫一：災害地理資料倉儲系統之研究與建置 目前國內各種不同的災害資料，都分散在不同權責單位的資料庫中。 本子計畫之目標為整合國內分散在不同權責單位資料庫中的各種不同災害 資料。本研究將建立災害資料倉儲系統，與各單位資料庫建立連結，每隔 一段固定時間自動收集彙整這些災害資料。為了能提供空間查詢與一般查 詢交互索引的功能，各類災害相關資料也將盡可能結合空間資料，才能方 便其他系統所使用。 各類災害專家 一般社會大眾 政府各災害主管單位 各大新聞媒體網站 中時電子報 聯合新聞網 其他 新聞網站 內政部 經濟部 行政院農委會 交通部 行政院環保署 第一線 勘災人員 各級災害應變單位 災害應變中心 災害應變小組 第一線 勘災人員 子計畫三 結合PDA/GPS/GIS建立 即時災情資訊彙報系統 之研究與建置 子計畫二 應用XML建立災害資訊網路之 標準交換語言 災害新聞彙整系統 子計畫一 災害地理資料倉儲系統 之研究與建置 各類電子地圖 水資局 資料庫 公路局公路通 阻資料庫 其他各災害權責 單位 防災資料庫 地震中心 防災資料庫 消防署災情傳遞 系統資料庫 總計畫之 空間災情通報及 防救災知識管理網站 IINTERNET 總計畫 運用知識管理建立台灣地區災害資訊網路之研究 計畫整體架構
3.1.2 子計畫二：應用 XML建立災害資訊網路之標準交換語言
XML(eXtensible Markup Language)，是目前網際網路應用上非常熱門的 技術，由於其跨平台的特性，可以在各種作業系統及硬體間流通，如 MS-Windows、UNIX、Win-CE、Palm 等，且行政院研考會於民國 88 年頒 定的行政資訊系統電子閘門功能規範即規定：資訊系統間互連時之資料傳 送的方式及內容格式，其中紀錄編碼採用 XML 技術，其應用潛力非常雄 厚。為了能與國內行政資訊系統接軌，本計畫擬應用 XML 技術，建立防救 災上游資料提供單位資料交換的標準，以使不同層級的防救災單位可以利 用各種傳輸方式(有線、無線)將擁有一致標準的資料，傳播至彼此的電腦上 (個人電腦、PDA)，並使用這些資訊進行災害防救決策。 3.1.3 子計畫三：結合 PDA/GPS/GIS 建立即時災情資訊彙報系統之研究與 建置 研究利用數位助理機、全球定位系統及地理資訊系統規劃開發一本土 性、高效率及低價位之即時現場災情空間與屬性資訊蒐集作業系統，並結 合國科會防災計畫辦公室資訊組已建置之單機與網際網路地理資訊系統， 作災情資訊展示，來提供給政府及媒體單位作即時災害地點空間定位及查 詢之功能。 3.1.4 災害新聞彙整系統 本系統主要目的為隨時收集各類線上災害相關新聞並加以分類歸檔， 分類的依據來自新聞標題或其內容所包含的關鍵字。這些關鍵字包括災害 用語（如納莉颱風、地震、坍方、爆炸、土石流）、地址、各類地標名稱（如 加油站、醫院）與道路設施名稱與樁號（如中正路、永和橋、后里收費站） 等。分類之後的新聞資料，能從關鍵字判斷得到地理位置者，將由系統自 動附加其座標位置﹔而未能從關鍵字判斷得到地理位置者，則由人工作業 補上對應的地理位置。
3.1.5 網際地理資訊系統 (Internet-GIS) 採用 Autodesk MapGuide 系統，該軟體服務對象主要為一般民眾，透過 Web 介面提供即時地理相關之各類災情資訊與新聞報導。本系統以及各類 地圖檔案由防災國家型計劃辦公室提供，所提供之各類災害資訊則是整合 自各政府機關資料，以及前述的兩套系統。 3.1.6 災害彙整網站 為建立一般大眾對於災害資訊單一的窗口，因此設置災情彙整網站， 以提供一般民眾上網查詢災情現況及取得相關資訊。本網站以資訊管理的 角度出發以及站在民眾、政府單位，彙整相關資訊做通盤全面性的規劃， 在救災的過程中，如何將損害程度減至最低，則有賴於資訊的正確以及時 效性。由於政府單位已有災害彙整通報網站（如防災國家型計畫辦公室）， 因此本計畫的研究成果將直接和這些網站連結，不再另行建置網站。
3.2 系統運作模式
本計畫所設計的系統，在平時即可提供各災害主管單位使用，以進行 各類小型災害狀況的管理。而在重大災害發生時，各災害主管單位及各級 災害應變單位（災害防救會報、災害應變中心及緊急應變小組）皆可以透 過本系統來掌握現地狀況，並透過網際地理資訊系統或網頁圖文來公布災 害現況。 重大災害發生 中央災害應變中心 緊急應變小組 直轄市縣市災害應變中心 緊急應變小組 鄉鎮市災害應變中心 緊急應變小組 現地勘災人員 內政部 第一線警消人員 經濟部 第一線工程人員 行政院農委會 第一線勘災人員 交通部 第一線工程人員 行政院環保署 第一線勘災人員 勘災回報 地理資訊系統 災害彙整網站 動態新聞彙整系統 中時電子報 聯合新聞網 新聞網站其他 ... 重大災害發生時期 系統運作模式 災害資料倉儲 網際地理資訊系統 圖2-2 重大災害發生時期系統運作模式四、 災害資料倉儲系統之系統需求
4.1 資料庫系統需求
4.1.1 連結遠端資料庫 Ø 資料庫連結方案 能充分運用各災害權責單位的即時資料，是本系統能提供完整資訊的 重要關鍵。因此直接或是間接地取得各分散單位的資料，並轉換成適合本 系統使用的資訊是極為必要的工作。由於安全性問題，尤其以目前駭客猖 獗的情形，因而目前任何重要的資訊系統，尤其是資料庫系統，一般都會 有防火牆的保護，是故直接遠端連結資料庫已變得不可行。而現階段要如 何間接取得完整的災害資料，透過 internet 以 XML 交換資料是比較可行的 方法。子計畫二「應用 XML 建立災害資訊網路之標準交換語言」乃針對此 一需求而進行研究。 Ø 資料彙整 資料取得之後，尚需要轉換成為一個統一的型式並進行彙整，以利於 前端應用程式的使用。當需要處理各類不同來源的災情資料間的複合查詢 或分析時，統一的資料格式是首要先決條件。但各種不同單位的資料庫， 其設計本身具有不同的風格，甚至也多有未做好正規化的不良設計，因此 資料清洗 (data cleansing) 的功能，資料轉換的規則庫 (rule base) 建置，都Ø 座標自動對應 由於大部分的災情資料只有災害地點的描述，確切的座標不見得包含 在資料內，因此需要能夠自動賦予這些資料的空間座標。由於無論是精確 的座標轉換 (例如地址座標對應或道路樁號對應) 或是概略座標範圍 (如 鄉鎮村里界) 的粗略表達，對於空間的分析及相關決策支援都能提供有效的 輔助。因此所有具備地點描述的災害資料，都應當盡可能的賦予空間對應。 4.1.2 即時災害查報之資料 理想的及時災害查報系統需要具備高度的機動性，並且要能回傳確實 的座標位置，因此子計畫二的目標即是設計以 PDA 為平台的即時災情資訊 彙報系統。而在資料庫的設計上，也必須要能夠配合該系統的需求，包括 支援各類型災害的查報、線上查詢、即時資料分析服務等。由於該災害彙 報系統有搭配 GPS 設計，因此可以很輕易取得災害座標資料，伺服器端不 需要再進行資料座標對應轉換的工作。 4.1.3 災害新聞之彙整資料 線上及時災害新聞在有些情況下會比主管機關的勘災人員更能提供及 時性的資訊，例如九二一大地震時期交通中斷，第一線的新聞媒體記者反 而常常最先發現災情。另一例是 SARS 疫情蔓延期間，疑似 SARS 病例在 正式通報衛生署前，也常常早已被新聞記者給披露出來。因此能即時線上 取得災害新聞資料，將可以使得災害通報系統更為完善。本計畫基於這個 考量，因此另外開發新聞彙整系統。而該新聞彙整系統所需要的資料庫支 援，也是本資料庫設計上需要考量的重點。 由於新聞資料刊登在電子媒體上的形式不一，因此需要針對不同的網 頁規範不同的擷取規則，以求能取得正確的資訊。另外災害發生地點的描 述更為模糊，且一般都藏在眾多的文字當中，因此能從關鍵字取得地點描
述，再從該地點描述自動找出相關座標對應，將是重要的一環。 新聞資料除了能夠提供最新災害相關報導以外，是否能夠在進行進一 步的加值運用，是相當值得探討的。但以現階段來說，這方面資料庫的設 計仍以新聞報導為主。
4.2 資料倉儲系統需求
建置災害資料倉儲的目的，在於能夠即時提供各級災害處置的相關決 策者，即時線上分析處理(On-line Analytical Process, OLAP) 的工具。其主 要功能種類包括： 1. 彙整(Roll-up)：能夠隨時提供各種不同規模的彙整(Roll-up)並提供所 需的各類統計數字。例如全省因某災害專案造成的傷亡人數統計、 建物損毀統計等。 2. 細化分析(Drill-down)：針對上述的統計數字，其背後的實際內容進 行不同細度的分析，以至最原始完整資料的直接提供。例如在「台 北縣」的傷亡統計數字中，「65 歲以上」、「男女各別」的死亡人數的 統計，以及這些人的名單和個人資料。3. 分類彙整(Slice and dice)：針對各種不同災害類型，或者不同的專責 部門需要針對特殊屬性值進行資料彙整時的需求。如「全省」因「土 石流」災害所造成的「房屋全毀」數。 4. 轉置(Pivot or Rotate)：因應特殊的查詢需求，轉換不同的維度來彙整 資料。 上述這些功能，都是災害發生時，各級單位主管在災害狀況掌握以及 進行相關決策時，最需要的重點功能，為救災決策支援上最關鍵的一環。 然而目前台灣現行的災害傳遞、防救災資訊系統，卻普遍缺乏提供此類的 功能，對災害緊急應變的功能支援有限，也直接影響到救災的決策品質，。
的主要資料表如災害原因專案、災情、以及縣市災情統計等，所記錄的欄 位多為統計資料。這些資料的更新以及正確與否，完全仰賴應用程式的檢 查，而且諸多不同維度下不同細度的統計資料，在維護上將更加困難，難 保應用程式在檢查更新上不會有所遺漏。另外由於不同層級的災害記錄多 有重複類型的統計數字，將引發資料重複的疑慮。而且該系統將對於個別 統計數字，非但無法再產生其背後較特殊細分的統計數字，甚至連被統計 的個體詳細資料，也無法提供。 因此本系統目標將著重在建立能有效提供線上分析處理功能的資料庫 架構，並建立防救災所需的各類型維度和資料彙整方塊(Cube)。以期能確實 支援防救災作業，並作為各類防救災資訊系統發展分析功能的重要支撐。
五、
資料庫結構設計
本系統災害通報的運作模式及資料需求，主要參考消防署「中央防救(處 理)災情傳遞資訊系統」之資料庫及其現有系統功能，針對資料倉儲的功能 需求考量，因此在資料庫的結構上有大幅度的變動。其中包括針對災害本 身的主要回報資料、災害發生所引發的其他類型災害資料的建置方式（以 公路通阻為例）、災害災情詳細資料、空間對應資料的建構等，均從利於資 料倉儲運作的前提為出發點設計。 為節省篇幅，本節說明略去許多較為瑣碎不重要的資料表，僅就關鍵 的觀念搭配示範性的資料表加以描述。5.1 災害災情主要資料
災害災情主要資料包括災害專案、災害案件、以及災害報告。其中每 一筆災害專案(HazProject)的紀錄對應一個大型的災害專案，例如納莉颱 風、331 地震、大規模火災等。災害專案資料建立的時間，大抵從大型災害 發生或者被預測到的時間點開始，專案結束時間則以災害過後一切救災活 動結束為建議時間。 災害案件(HazCase)則是記錄災害專案發生時期，各個發生在不同的時 空環境下的所發生災害事件，並記錄其所屬災害類別，發生時間、以及主 管該地區該類型災害的政府單位代碼。每一筆災害案件的發生，在勘災及在平時無重大災害的情況下所發生的小型災害案件，如冰雹、車禍、 小型火災等，則不附屬在任何災害專案下，因此在災害專案代碼的欄位上 使用 0 值代替(HProjId=0)。 災害類別(HazType)在建置上採用樹狀的結構來管理，從資料倉儲建置 的觀點來看屬父子式階層，每一種災害類別都有其父類別，例如「爆炸」、 「建築物火災」及「森林火災」等子類別都屬於「火災」這個父類別。災 害回報時，災害類別的選擇只允許使用葉節點的類別。 災害災情的詳細資料，主要都附加在災害案件以及災害報告下加以延 伸，延伸的作法在下一小節將加以說明。
5.2 災情細節資料表
災害災情的詳細資料，即時的案件相關彙整資料主要由災害案件延 伸。而各時間點詳細資料的回報，仍須經由災害報告來延伸，依照各種不 同類型的災情資訊，本研究提供數種建置的範本，分別以受害人員及其避 難收容、建物損毀、維生管線損壞及維修，以及公路阻斷為例子說明。其 中公路通阻由於在工程作業上亦可視為一個案件，因此留在下一小節說明。 下圖說明災害案件發生時，記錄受害人員的作法。其中核心的資料表 為受害人員列表(VictimLst)。在該表中紀錄包括受害者事件所屬的災害案件 代碼、受害者詳細資料表(Victim)的關連代碼、在哪一份災害報告中被提報、 受害類型(SufferType: 死亡、失蹤、重傷、輕傷、受困等)、目前在哪一個 使用中的收容避難所(RefugeUse)，受害狀況具體說明，以及安置處理的措 施。 收容避難所類別(RefugeType)包括醫院、學校、大型廣場等。在收容所 啟用的情況下，才可收容災害受害者。災害報告資料由於各階段報告的重複性高，因此並不直接納入資料倉 儲，替代的方法是災害案件也和詳細資料有所連結，而且必須隨時與最新 災害報告的資料保持一致性。只有災害案件所連結的資料，會在資料倉儲 中建立線上分析所需要的資料方塊(Cube)。 上圖則說明建物損毀以及維生管線災情的建置方式。這兩種災情資訊 都有分別連結到災害案件以及災害報告。不同於受害者資料，一個建築物 不會同時有多種受損事件，因此在建物損毀的列表(BldDmgLst)直接列示其 詳細資料即可。 維生管線的損壞資訊由於主要是統計資料，因此在每階段的報告中， 對連結到災害案件的統計資料加以更新。維生管線的類別包括水、電、瓦 斯、電話等。
5.3 災害災情延伸資料表
部分災害案件所延伸的災情細節，由於工程人員在救災過程的報告需 要因此可以採用類似災害案件與災害報告的架構來處理。以下以公路通阻 為例說明這類作法。 當公路阻斷事件發生時，就會產生一個公路通阻案件(Roadblock)。發 生公路通阻案件的原由，可能來自於一個大的災害專案下的某個災害案 件，也有可能僅僅是平常的維修動作。因此在公路通阻案件資料表中包含 了所對應災害案件的連結欄位(HCaseId)，但這個欄位也可以是 0 值，表示 該公路通阻案件並非源自於任何災害案件。 類似災害案件的作法，一個公路通阻案件可以包含多個公路通阻報告 (RbReport)，以記錄工程人員各階段的修復進度。不同於災害案件欄位的通 用型設計考量，公路通阻案件資料表增加了許多業務相關的資料欄位，包 括公路基本資料(Road)、起始與終點樁號、阻斷程度、阻斷時間、預計搶通 時間、實際搶通時間、主管工務段的代碼等。同樣的情形也出現在公路通 阻報告中，具備了業務相關的欄位。 替代道路(AltPath)則延伸自公路通阻案件，類似災害案件所延伸的災害 災情詳細資料。5.4 空間描述資料表
本系統資料庫的另一個重要設計是引入地理位置對應的資料，使各種 關連式資料都能有相對應的空間資料。除了各類資料包括災害案件、行政 區域等的空間對應查詢外，也需要具備從空間範圍查詢關連式資料的功 能。另外在資料倉儲的設計中，空間維度的階層關係雖然是建立在行政區 域的層級上，但是在一個災害案件可能有多個空間對應資料的情況下，設 計上將更為複雜。 下圖是空間對應的作法，主體為空間對應資料表(Geometry) ，為了利 於資料倉儲的設計，各個需要空間對應的關連式資料表(例如 HazCase)都有 中間的資料表(例如 GeoHazCase)來連結，使該空間對應資料表得以保持和 多種資料表之間的一對多關係。空間對應資料表的設計如下表。其內容包含行政區域代碼，此部分為 資料倉儲空間維度的依據。圖元維度則描述該空間物件的型態，0 維即代表 點物件，1 維代表曲線物件，2 維代表多邊形物件，3 維則是物體。在本系 統中只會用到 0 至 2 維。而空間資料則由節點數和節點座標資料此兩欄位 存放。為了方便起見，維度欄位大於 3 時，節點數和節點座標資料將無效， 該空間物件直接引用行政區域所對應的空間資料。 Geometry 空間(地理位置)詳細資料 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 TableId 對應資料表代號 GovRgnId 包含本物件之最細分行政區域 Id int 4 Dim 圖元維度 tinyint 1 SegNum 節點數 int 4 GeoData 節點座標資料 image 16 MinX 左界 float 8 MinY 下界 float 8 MaxX 右界 float 8 MaxY 上界 float 8
六、 災害資料倉儲系統設計
本災害資料倉儲系統主要使用的軟體為 Microsoft SQL Server 2000 以 及其所附的 Analysis Services。災害資料倉儲的運作包況三個步驟： 1. 資料收集 2. 建立資料預儲 Cube 3. 資料分析6.1 資料收集
災害資料倉儲的資料來源包括： Ø 各單位災害資料 Ø 現地即時勘災系統 Ø 災害新聞彙整系統6.2 建立資料預儲 Cube
當災害資料及其相關的詳細資料已存放進資料庫之後，我們就可以使 用 SQL Server 所附之 Analysis Services 開始建立資料預儲的 Cube。在這裡我們建立兩個 Cube 為例，包括受害者的預儲 Cube 以及建物損 壞的預儲 Cube。
6.3 內政部消防署之災害通報型態--以娜克莉颱風為例
Ø •花蓮縣台九線一六九公里處於因土石崩落交通中斷，由公路總局 派員搶修中，預計十日七時三十分搶通 Ø •台中市南屯區萬和路二段二十八、三十號前河堤缺口 Ø •台北縣石碇鄉磨石坑六號附近，縣道一○六乙線道路坍方，坍方 面積約長二十公尺、寬五公尺，道路寬度約尚餘二至三公尺，由工 務局派員前往處理中，預計十日修復。 Ø •宜蘭市中山路、舊城東路、和平路、吳沙路淹水約三十公分高， 目前積水已全部消退，無災情發生。6.4 資料分析 --使用 Excel 進行樞紐分析之範例
D_Project 娜克莉颱風 Area Name 資料 中部 北部 東部 南部 總計 * 土石崩落 Dead 0 0 0 0 Miss 0 0 0 0 Wounded 0 0 0 0 其它 Dead 1 1 2 Miss 0 0 0 Wounded 0 0 0 房屋毀損 Dead 0 0 Miss 0 0 Wounded 0 0 海上火警 Dead 0 0 Miss 1 1 Wounded 9 9 強風暴風 Dead 0 0 Miss 0 0 Wounded 1 1 淹水水災 Dead 0 0 0 Miss 0 0 0 Wounded 0 0 0 堤防缺口 Dead 0 0 Miss 0 0 Wounded 0 0 堤防潰決 Dead 0 00 1 2 3 4 5 6 土石崩落 其它 房屋毀損 海上火警 強風暴風 淹水水災 堤防缺口 堤防潰決 中部 北部 東部 南部 D_Project 娜克莉颱風 Haz Id Name Area
七、 子系統連結應用--災害新聞彙整系統
7.1 系統特點
Ø 自動化資訊收集(Automation) 過去，政府單位及民間新聞媒體，對於災情災害資料都有一分自己 的資料庫，並各自維護這些資源。為了能結合政府、民間各單位的力量， 將防救災的資源更充足，資訊更完整，於是資訊的整全及交換就十分重 要。 以往政府單位要整合災情新聞，必須以人工方式一一走訪各大新聞 網站，點選每一個連結，以人工瀏覽資訊的內容，再彙整到該單位的資 料庫中。以目前網路上幾個最大的網路新聞資訊提供者(ICP; Internet Content Provider)來說，每日總共會有數以百篇的新聞資料不斷產 生。面對這麼龐大的資料，如果能讓系統自動擷取、判斷、最後收集到 資料庫中，對於工作的效率將有十分大的幫助。本系統的主要目的，就 是希望能透過資訊擷取技術，使這樣繁重的工作能以電腦系統代替。 Ø 即時性(Real time) 如前項所述，以人工整合的問題除了成本高昂、效率低落之外，對 於收集到的資訊也缺乏即時性。當災情的救援與疏通十分緊急時，一分 一秒都非常可貴。例如道路的通阻、人員的傷亡與圍困等等，這些資訊Ø 適應性(Adaptive) 為了能適應混沌多變的的網站生態，系統的適應性也是十分重要 的議題。目前自網路上擷取資料的應用系統，多半只能擷取特定的特 定的頁面、特定的格式。若格式有任何變動，則必須重新修改程式， 才能適應新的環境。然而，網站的版面時常有改變的可能性，而且永 遠不知道會發生在何時何地。 本系統將網站的資料邏輯獨立於程式之外，以 Script 來定義如何 擷取網路上的資料，並描述該資料的意義。Script 亦提供了一定程度 的相容性，能適應微小的改變。如此以來，若網站頁面有任何變更， 只需要微幅修改 Script，甚至不用修改，就能適應新的環境。 Ø 擴充性(Extensible) 由於目前自網路上擷取資料的應用系統，多半只能擷取特定的特 定的頁面、特定的格式。若要整合新的網站資料，由於格式不同，所 以必須為新的網站加寫新的程式。由於本系統將網站的資料邏輯獨立 於程式之外，於是只要撰寫新的 Script。不需修改系統，就可以不斷 整合新媒體，達成擴充性的理想。
7.2 系統架構
下圖一及圖二分別表示的傳統網路資料擷取系統的架構及本系統的實 作方式。圖一中的系統必須為每個新聞媒體網站撰程式程，若網站更換版 面，則可能無法適應。因此較不具適應性與擴充性。 而圖二中的本系統，以 Script 定義資料邏輯，於是能在不修改程式碼的 情況下適應新版面，或是擴充新媒體。圖一、傳統網路資料擷取系統 圖二、本系統的實作方式 各大新聞媒體網站 中時電子報 聯合新聞網 TVBS ... 災情新聞彙整系統 中時電子報 內容擷取引擎 資料儲存 災情新聞彙整系統 聯合新聞網 內容擷取引擎 資料儲存 災情新聞彙整系統 TVBS 內容擷取引擎 資料儲存 各大新聞媒體網站 中時電子報 聯合新聞網 TVBS ... 災情新聞彙整系統 中時電子報 內容邏輯 Script 聯合新聞網 內容邏輯 Script TVBS 內容邏輯 Script ... 核心引擎 資料儲存
7.3 使用案例說明
我們將本系統的架構以下面的使用案例圖(Use Case)加以說明。首先， 在這個系統中包含了五個不同的角色：
1. 系統管理者(System Operator)：主要的工作在於負責設定系統的專案及 災害相關關鍵字，並執行系統的功能。
2. 新聞媒體 (News Content Provider)：當系統管理者進行擷取動作後，系 統會連上各新聞媒體擷取資料。
3. 資料複檢員 (Data Verifier)：當資料自新聞媒體下載完畢後，Data Verifier 可以對資料進行複檢，以確保資訊的品質。 4. 系統使用者 (System User)：系統使用者的身份可能是與災情相關的工作 人員，透過系統，他們可以得到彙整後的資訊，以利防救災工作的進行。 <<uses>> SystemOperator SystemManagement SystemOptionManager FixedKeywordManager DynaKeywordManager <<uses>> DataVarifier NewsGather NewsContentProvider DataCorrection NewsQuery <<uses>> User <<uses>> 圖三、使用案例說明
7.4 資料關連說明
下圖是本系統使用的資料庫結構。MediaData 代表新聞媒體的相關資 料，一個媒體可能有很多個“搜尋進入點”，進入點的資料記載在 MediaEntry 資料表中，包括如何存取這些新聞媒體的 Script。系統由每個進 入點中，依 Script 尋找符合需要的新聞，最後儲存於 NewsInfo 資料表中。 NewsInfo 中包含了新聞裡的相關資訊，如新聞標題、報導地點、報導人、 報導時間等等。新聞所屬的專案記載於 HazProj 資料表中。另外，災害關鍵 字記錄於 HazType 資料表。由於一則新聞會與多個災害關鍵字相關，所以 本系統將關係記載於 NewsHazType 資料表中。 圖四、資料關連圖7.5 後續研究及未來方向
本系統未來希望能往幾個方向繼續發展 1. Script 編輯精靈 – 一個友善的系統介面，能使系統管理者更方便產生新 的媒體資料擷取語言。未來希望能研發特定的編輯器，加速 Script 的撰 寫速度，將大幅提升本系統的實用性。 2. 語法完整性 – 目前的 Script 語法只能處理大多數的情況，面對 Internet 複雜多變的環境，需要更強大的語法功能，才能含括所有狀況，達成資 訊融通的目標。 整合地理資訊系統 – 為了使災情資料以最人性化，最友善的方式呈 現，未來將整合地理資訊系統，將公路通阻、椿號對映、地址座標等相關 資料標示於確切位置。方便救災人員及指揮系統掌握災情，進行統一的指 揮調度。八、 附錄一
資料表欄位結構
A.1 災害災情主要資料表
HazProject 災害專案 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HProjId 災害專案代碼 int 4 Name 專案名稱 varchar 50 StartDate 專案建立日期 datetime 8 EndDate 結案日期 datetime 8 FarmLoss 農業損失 int 4 ForestryLoss 林業損失 int 4 FisheryLoss 漁業損失 int 4 StockLoss 牧業損失 int 4 PrsnDeath 死亡人數 int 4 PrsnMissing 失蹤人數 int 4 PrsnHarmH 重傷人數 int 4 PrsnHarmL 輕傷人數 int 4 PrsnBlock 受困人數 int 4 PrsnRefuge 收容避難人數 int 4 RoadDmg 道路損壞數 int 4 RoadRep 道路修復數 int 4 RailDmg 鐵路損壞數 int 4 RailRep 鐵路修復數 int 4 BridgeDmg 橋樑損壞數 int 4 BridgeRep 橋樑修復數 int 4TeleBrk 電話中斷數 int 4 TeleRep 電話修復數 int 4 WaterBrk 停水數 int 4 WaterRep 停水修復數 int 4 GasBrk 中斷數 int 4 GasRep 修復數 int 4 BoatRefuge 船屋避難人數 int 4 HazCase 災害案件 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HCaseId 災害案件代碼 int 4 F.K HProjId 所屬災害專案代碼 int 4 HTypeId 災害類別 int 4 StartTime 災害發生時間 datetime 8 EndTime 災害結案時間 datetime 8 GovDeptId 主管單位代碼 int 4 PosiDesc 地點描述 text 16 HazReport 災害報告 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HRepId 災害報告代碼 int 4 F.K HCaseId 所屬災害案件代碼 int 4 RepNo 報告次號 smallint 2 RepTime 報告時間 datetime 8 ReporterId 報告人代碼 int 4 Content 報告內容 text 16 Suggestion 建議事項 text 16 HazType 災害類別 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HTypeId 災害類別代碼 int 4 SuperId 所屬父類別代碼 int 4 Name 類別名稱 varchar 30
A.2 災情細節資料表
Victim 受害者資料 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K VicId 受害者代碼 int 4 PrsnId 身分證字號 char 10 Name 姓名 varchar 20 Sex 性別 bit 1 Age 年齡 tinyint 1 GovRgnId 戶籍地行政區域代碼 int 4 Addr 戶籍地址 text 16 Tel 聯絡電話 varchar 50 Contact1 第一緊急聯絡人 varchar 20 C1_Tel 第一緊急聯絡人電話(可輸入多個號碼) varchar 50 Contact2 第二緊急聯絡人 varchar 20 C2_Tel 第二緊急聯絡人電話(可輸入多個號碼) varchar 50 VictimLst 受害者名單 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HCaseId 災害案件代碼 int 4 P.K VicId 受害者代碼 int 4 HRepId 提報該受害者的災害報告代碼 int 4 RfgUseId 所在避難所代碼 int 4 SufTypeId 受害類別(死亡、失蹤、重傷、輕傷、受困) tinyint 1 Condition 受害狀況描述 text 16 Treatment 救難處置描述 text 16 SufferType 人員受害類別 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K SufTypeId 受害類別代碼 tinyint 1Refuge 避難所 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RfgId 避難所代碼 int 4 Name 避難所名稱 varchar 50 RfgType 避難所類別(學校、醫院、廣場… … ) tinyint 1 Addr 地址 text 16 Sponsor 聯絡人 varchar 20 Tel 聯絡電話(可輸入多個號碼) varchar 50 RefugeUse 避難所運作 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RfgUseId 避難所運作代碼 int 4 RfgId 避難所代碼 int 4 StartTime 啟用時間 datetime 8 EndTime 關閉時間 datetime 8 Working 可使用狀態 bit 1 RefugeType 避難所類別 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RfgTypeId 避難所類別代碼 tinyint 1 Name 避難所類別名稱 varchar 20 BldDmgLst 建物損毀列表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K BldDmgId 建物損毀代碼 int 4 HazId 災害案件代碼 int 4 HRepId 災害報告代碼 int 4 Name 建物名稱 varchar 50 BldTypeId 建物種類 tinyint 1 DmgTime 損壞時間 datetime 8 DmgLvl 損壞級別 tinyint 1 Addr 地址 text 16 Content 損壞情形描述 text 16 Treatment 狀況處置描述 text 16
BldType 建物種類 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K BldTypeId 建物種類代碼 tinyint 1 Name 建物種類名稱 varchar 20 LivingLine 維生管線狀況 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HCaseId 災害案件代碼 int 4 P.K LLTypeId 維生管線類別代碼 tinyint 1 FailNum 中斷數 int 4 RepairNum 修復數 int 4 Content 狀況描述 text 16 LLReport 維生管線報告 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K HRepId 災害報告代碼 int 4 P.K LLTypeId 維生管線類別代碼 tinyint 1 FailNum 中斷數 int 4 RepairNum 修復數 int 4 Content 狀況描述 text 16 LLType 維生管線種類 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K LLTypeId 維生管線種類代碼 tinyint 1 Name 維生管線種類名稱 char 10
Photo 照片 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K PhotoId 照片代碼 int 4 TargetTblId 對應記錄之所在資料表 Id int 4 TargetRecId 對應記錄 Id int 4 ShotTime 拍攝時間 datetime 8 FilePath 檔案路徑 text 16 FileSize 檔案大小 int 4 PosiDesc 拍攝地點描述 text 16 Content 內容描述 text 16
A.3 災害災情延伸資料表
RoadBlock 公路通阻案件 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RbId 公路通阻案件代碼 int 4 HCaseId 災害案件代碼 int 4 RbType 阻斷類別 smallint 2 RoadId 阻斷道路代碼 int 4 LMStart 阻斷起始樁號點 int 4 LMEnd 阻斷結束樁號點 int 4 BlockLvl 阻斷程度 tinyint 1 BlockTime 阻斷發生時間 datetime 8 ExpectTime 預計搶通時間 datetime 8 RepairTime 實際搶通時間 datetime 8 GovDeptId 主管單位代碼 int 4RbReport 公路通阻報告 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RbRepId 公路通阻報告代碼 int 4 F.K RbId 公路通阻案件代碼 int 4 RepTime 報告時間 datetime 8 ReporterId 報告人代碼 int 4 BlockLvl 阻斷程度 tinyint 1 Content 報告內容 text 16 Suggestion 建議事項 text 16 AltPath 替代道路 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K AltPathId 替代道路代碼 int 4 RbId 公路通阻案件代碼 int 4 Content 替代道路描述 text 16 RbType 公路通阻類別 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RbTypeId 公路通阻類別代碼 smallint 2 SuperId 所屬父類別代碼 smallint 2 Name 類別名稱 varchar 20 Road 公路基本資料 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K RoadId 公路代碼 int 4 Name 公路路名 varchar 50 AltName 公路別名 varchar 50 StartLM 起始樁號 int 4 EndLM 終點樁號 int 4
A.4 行政劃分資料表
GovRgn 行政區域資料表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GovRgnId 行政區域代碼 int 4 SuperId 所屬上級行政區域代碼 int 4 Name 行政區域名 varchar 50 Class 行政區域等級 tinyint 1 Residence 戶口數 int 4 Population 人口數 int 4 GovDept 主管單位資料 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GovDeptId 主管單位代碼 int 4 SuperId 上級單位代碼 int 4 Name 單位名稱 varchar 50 SuperTitle 上級抬頭稱號 varchar 50 Tel 電話 varchar 50 ServTel 服務電話 varchar 50 Addr 地址 text 16A.5 空間描述資料表
Geometry 空間(地理位置)詳細資料 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 GovRgnId 包含本物件之最細分行政區域 Id int 4 Dim 圖元維度 tinyint 1 SegNum 節點數 int 4 GeoData 節點座標資料 image 16 MinX 左界 float 8 MinY 下界 float 8 MaxX 右界 float 8 MaxY 上界 float 8 GeoGovRgn 行政區域空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K GovRgnId 行政區域代碼 int 4 GeoHazCase 災害案件空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K HCaseId 災害案件代碼 int 4 GovRgnId 包含本物件之最細分行政區域 Id int 4 GeoRoadblock 公路通阻案件空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K RbId 公路通阻案件代碼 int 4 GovRgnId 包含本物件之最細分行政區域 Id int 4GeoAltPath 替代道路空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K AltPathId 替代道路代碼 int 4 GeoRefuge 避難所空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K RfgId 避難所代碼 int 4 GovRgnId 包含本物件之最細分行政區域 Id int 4 GeoBldDmg 建物損毀空間對應表 Key 欄位名稱 說 明 資料型態 佔用空間 Null P.K GeoId 空間物件代碼 int 4 P.K BldDmgId 建物損毀代碼 int 4 GovRgnId 包含本物件之最細分行政區域 Id int 4
九、 附錄二
災害新聞彙整系統操作說明
以「娜克莉颱風」為例，說明如何使用這個系統。工作人員的操作流 程如下：首先進入這個系統，在資料庫中建立颱風的專案資料、相關關鍵 字。按下「執行擷取」，即可自動到各媒體網站搜尋、分析新聞內容。並取 得發生地點、報導時間等相關資料，供後端系統進行災情控管、分析。B.1 系統設定
進入系統主選單後（如圖五），請選擇「系統設定」選項，進入系統設 定功能表，如圖六所示。 圖五、主選單(1) 專案管理 進入設定之後，選擇「專案名稱」為「娜克莉颱風」。若需要更完整的 功能，則可按下「進階…」按鈕，系統管理者可以在這裡建立新的專案， 或是設定專案細節。如圖七所示。 圖七、專案細節 (2) 災害類別管理 回設定交談窗之後，系統管理者可依「娜克莉颱風」的屬性，設定「災 害類別」。例如「水災、颱風、…」，這些設定將成為擷取、過濾資料的依 據。 若需要更完整的功能，則可按下「進階…」按鈕，系統管理者可以在 這裡建立、管理災害關鍵字。 圖八、關鍵字管理
(3) 新聞媒體管理 接著，選擇要在哪些媒體網站搜尋資料，使用哪些「進入點」。如果要 新增或管理媒體資料，可以在「媒體」欄按滑鼠右鍵，如下圖九、圖十所 示。 圖九、管理媒體 圖十、管理媒體
(4) 媒體進入點暨 Script 管理 要將「進入點」加入搜尋列表，請選擇一項媒體的一個或多個進入點， 按下「→」，進入點就會加入列表。要刪除請按「←」。如果要對進入點的 詳細資料進行管理，可以在「搜尋進入點」列表上按下滑鼠右鍵，即出現 進入點編輯器如下圖十一所示。 上半部為媒體、及媒體包含的進入點資料。點選進入點資料後，下半 會出現該進入點的 Script 語法。設定完成後，按下儲存 Script 即可。 圖十一、進入點編輯
B.2 擷取資料
完成以上步驟之後，回到主選單按下「執行擷取」，即可自動到各媒體 網站搜尋、分析新聞內容。並取得發生地點、報導時間等相關資料，供後 端系統進行災情控管、分析。示意如圖十二。圖十二、執行擷取
B.3 檢視資料
擷取完畢後，資料將存入資料庫中，待資料複檢員進行檢查，即可開 放供前端系統取用，讓災情相關工作人員能對災情資訊進行分析、控管。
十、 參考文獻
Ø 黎漢林、李俊慶、林立中(1999)，網際地理資訊系統設計與應用。 Ø 孫志鴻、王聖銘、丑倫彰、游怡芳、尹昌敔、尹昌堯、林秀芳(2000)，災害管理決 策支援系統架構規劃與雛型系統之建置，八十八年度防災國家型科技計畫— 整合性 專案研究報告，報告編號NAPHM 88-15。 Ø 林美聆、莊睦雄、洪鳳儀、張博翔(1999)，陳有蘭溪流域之自然環境資料庫之建立 與分析，八十七年度防災國家型科技計畫— 整合性專案研究報告，報告編號 NAPHM 87-06。 Ø 施鴻志(1990)，都市災害資訊系統建立之研究-地理資訊系統之應用，行政院國家 科學委員會防災科技研究報告79-22 號，計畫編號 NSC 79-0414-P006-15B。 Ø 孫志鴻、朱子豪(1990)，台灣地區環境資料庫之建立，台灣省政府環境保護處委託 計畫。 Ø 孫志鴻 (1991)，空間決策支援系統之研究，中國地理學會會刊，第十九期， pp.145-156。 Ø 孫志鴻、王聖銘、丑倫彰、楊佳璋、謝奇峰、尹昌敔、游怡芳、詹仕堅(1999)，防 救災空間決策支援系統之研發，報告編號NAPHM 87-10。 Ø 國家地震工程研究中心(2000)，921 集集地震地震資料分析與災情資訊管理系統， http://gisdb.ncree.gov.tw Ø 孫志鴻、朱子豪(1990)，台灣地區環境資料庫之建立，台灣省政府環境保護處委託 計畫。 Ø 孫志鴻 (1991)，空間決策支援系統之研究，中國地理學會會刊，第十九期， pp.145-156。Ø 施邦築、韓茂樹、文一智(1999)，災害危險度相關資料蒐集及資料庫建立（示範區） 研究期末報告，內政部消防署委託研究報告書。
Ø 賴進貴、孫志鴻，(1994)，台灣地區數值土地利用資料庫建立之研究，行政院農業
