唐政委、各位好朋友，大家午安，今天是民生公共物聯網，我想預算都核下去的正式會議。

今天最重要的是，這一陣子最重要的，我們把未來的那一些重點來說明一下，還有共同的common space，大家調整一下。

有關於重點的部分，兩位政委有非常清楚地指示，因為我們看到資料其實都沒有辦法達到這樣的要求：

第一，我們不一定要把它分成計畫，我們要分成水、地、空、災分成四個群，這四個群要非常清楚的亮點，這個是每一年都要訂亮點，也就是老百姓有感的亮點，而這一個亮點請大家務必說明，道明會發一個表給大家填，也就是每一年的計畫執行花了這麼多的預算，讓老百姓有感的亮點。

像水利署的案子，可能只有四個縣市比較有感，你就要針對哪四個縣市來說明，這樣也行。

像空品的這一件事，大部分會放在中南部，把做了這一件事對當地老百姓有什麼感覺，這個是一件事。

老闆們要求要有質化的指標，我可以做一個很簡單的說明，如果大家有寫過專利這一件事，第一個claim就會寫得很清楚，也就是做這一件事包含什麼，透過什麼樣的技術、可以達到什麼樣的夠能，以創造什麼樣的好處，所以我希望質化的指標，大家可以用第一個專利模式來寫，並不是寫幾個而已，湊不成一個，這個是要想一下。

每一個計畫都是量化指標，這個我可以同意，但整個政策的量化指標，不要寫很多，寫兩個左右就好了。什麼意思呢？這個指標是用行政院跟部來看，而不要從計畫的角度來看，今天做了這一件事，在行政院層級或者是部層級可以達到什麼樣的效果？我舉一個例子好了，像我們講水資源的這一件事，我們希望達到最大的效益是什麼？是水的有效利用度嗎？或者是水品質的管制？又或者是水的分配是否合理化？又或者每一度水對老百姓或者是對國家產業的貢獻？

你可以訂很多種，像這一種是行政院或者是部會配合的指標，訂這樣的指標就好了，這樣可以嗎？這個量化指標，現在這一個數字是多少，明年之後又會達到多少，後年會達到水的有效運用度，各位比較專業，所以可以這樣做。

我建議現在訂的指標不要是絕對值的指標，因為絕對值的指標會忽略掉成本的效益，所以這一個指標在訂的時候有outcome跟input的比例，沒有任何東西沒有成本的，如果沒有成本的話，這就是假的，行政院層級的指標跟部層級的指標是放在部裡面，是水、地、空或災的，這個是一開始要先說清楚的。

不要把計畫書的指標搬出來，這個並不是我們要的，而是通過計畫書的審議來看，但整個計畫要跟部、院連結，我們要看的是連結一塊的指標，所以我們沒有要求大家要訂很多指標，我們希望訂到重點的指標，大概是這樣。

剛剛講的那一些，是因為11月中下旬開始，院長會從屏東開始，先把東部繞過一圈，然後再回高雄，再從左邊回到台北，每一個縣市都會去看前瞻基礎建設，還有長照跟那個地方的關聯是什麼。

因為這樣的關係，我們的語言變成必須要充分轉譯，因為不是只是讓地方政府瞭解，而且事實上是要讓民眾或者是地方市議員都可以瞭解的程度，所以剛剛副執秘才這麼強調這一件事。

他們不太可能會去看我們核定版的計畫書，然後從裡面抽取出有意義的部分，這個工作勢必是我們每一次在報告裡面聽了之後，決定出一些部分來，然後下一次再來檢視這一個東西從地方的角度來看，他們有感陳述的方法是什麼，並不是我們現在去揣想，我們要把自己價值主張的質化部分，以及效益的這一個部分，把這兩個部分用一般人的話講出來。

這個計畫的特色，裡面基本上沒有國家機密，個人資料也是非常少，基本上都是以公開資料、感測為前提，所以我們目前這一個會議，因為我當主席，所以會做逐字紀錄，跟以前一樣，各位的簡報是可公開，如果裡面有哪一些要抽的話，裡面有十個工作天的時間，大家講的任何字都可以改或者是拿掉，簡報如果要抽換的話，也請讓我知道。

十個工作天之後，差不多是在院長要開始下鄉行程的時候，這整套東西都會讓外面知道，才有可能讓媒體及地方的議員們有準備的時間知道我們在說什麼，大概是這樣，謝謝。

首先跟各位回顧一下，這個是我們在工作會議中提出，由國網中心建構的Data Hub產業平台架構，我們會搜整各部會提出的感測資料、調查分析資料、以及政府資料開發平台上的資料，然後進行資料的介接、收集、儲存、備援及永久保存的動作。我們會提供高速運算跟GPU的主機，提供給各部會及學研界作一些模式分析和大數據運算的支援。Data Hub主要是提供產業界進行加值開發，所以我們會提供一些網路服務，包含資料查詢、下載和地圖服務，最主要是希望提供API，未來讓產業界能作後續應用。

對於感測資料傳輸標準，因為現在各部會的感測裝置可能是不同的來源，也有不同的資料模式，我們希望能採用國際標準，目前選擇的是由OGC所訂的SensorThings API，來解決資料異質性的問題。這個標準現在可以進行感測資料和裝置的讀取及刪除，也可以透過API做一些複雜的查詢功能。

除了感測資料，我們也會收集災害示警資料，這個部分會跟災防中心合作，目前的資料計有二十一類，明年會繼續增加新的資料項目，包括空品的示警資料也會進來。

另外，有關於圖資的部分，因為各單位有自己發布的需求跟服務平台的規劃，所以我們目前建議各單位可以自行選擇使用免費或者是需要付費的圖台，而底圖希望能採用內政部資訊中心，或是內政部國土測繪中心所發佈的，希望圖資的座標系統能一致，之後整合才不會有問題。

綜整前面的部分，我們分三類的資料，分別是感測資料、示警資料及圖資的資料。希望用符合國際標準的格式，會提供給外界的檔案格式包括JSON、XML，WMS或GeoJSON等。

目前對各分項進行資料的盤點，包括106年、107年度，由各分項會提供我們介接的資料，一部分是感測資料，一部分是災害示警的資料。

因為各單位的感測裝置還在持續建置當中，所以今年度大概是以現有的空品資料及示警資料為主，明年度會逐步增加感測裝置和資料的介接。

另外一方面，我們也針對各分項計畫，對國網中心的資源需求作調查。目前的調查結果是，空品物聯網部分，會協助科技部對所徵求的計畫，提供3公里乘3公里解析度的運算資源，後續會提升到1公里乘1公里，預估會提供三千多個計算核心，來支援科技部的研究計畫。

此外，國震中心也規劃後期會與學研單位合作進行研究，也會需要我們提供一些運算資源。

水利署希望我們能夠協助他們作資料保存及業務系統的備援，之後他們如果有做大數據或雲端預算的服務，也希望我們可以提供運算支援。

報告目前的結論是，在各部會提出來的交換格式，我們希望以OGC的國際標準為主，以方便後續的檔案的整合應用。

106年、107年主要以感測資料、示警資料為主。圖資部分是進行加值、產製結果及分析之後，才會有圖資產生，我們希望用相同的座標系統來交換，這邊是我的報告，謝謝。

我能不能請教一下，因為剛好國發會跟經濟部最近都在推「智慧城市物聯網」，我不知道你要求的標準跟他們要求廠商建置的標準（是否一樣）？因為智慧城市很多會用到物聯網，在標準、間接跟API最好一致，不然會不一樣。

在傳輸規範上，我們還是在研究是要用DDS或者是用哪一個來作測試。

我們先提出來的標準主要是data model的部分，傳輸資料的內容跟格式希望是一致的，我們會配合內政部資訊中心也在做國土資訊的標準推動，我們會協助各部會作資料格式的轉換，未來的格式也是開放的，會變成內政部整個國土資訊的標準。

國網這個部分，到底要做什麼？我聽到很多技術，最後的呈現是什麼？對外部的人員到底是怎麼樣？你有一個網頁或者是團隊來協助他們使用這一些資料或者是怎麼樣？現在看起來都是在解決技術的問題，我不曉得你每一年準備deliverable的東西是什麼，除了技術問題之外，要協助使用者嗎？使用者是專業或者是外部的部會或者是學校或者是人名？

我補充一下，我們現在的工作項目是跟各部會討論他們提出來的資料格式，裡面的data model是什麼樣的格式，我們會協助轉換符合目前各部會的資料來作統一的標準規範。

第二個部分我們會協助各部會作資料蒐集，對於民眾跟學、產業界的部分，我們會提供感測資料跟測試環境，一般的廠商進行加值開發的時候，可以在我們的平台上用API的方式介接資料來測試，我們會宣告我們的資料跟標準是什麼樣的格式。學界目前是透過科技部的計畫來提供運算支援。

舉實際的例子，像環保署測站資料，這一些都是現成的，你的意思是，這一張圖的右上角，我什麼時候可以在Data Hub的網站上，可以看到這一些資料？因為我瞭解在CDX或者是其他的地方都有，從這一個角度來看，放在高解析度的資料展示平台及Web Service查詢下載的這兩個部分，什麼時候可以看得到？

目前我們已經在做環保署資料的介接、測試，所以我們現在是用Open Data的資料來做，在今年會開放一些IoT平台上的資料來讓我們作介接，因為那兩個資料會不同。

所以兩邊的資料模式開始統一之後，我們就會做儲存，然後會提供服務，應該明年上半年就會讓一般的民眾或者是業界從我們這邊看到一些成果。

另外，因為Open API有寫入跟寫回，民間也可以接取資料嗎？

目前可以說呼叫一些服務。

所以這個是Web service的概念，並不是真的能夠存資料。

民間的資料還要不要存，我們還需要再看。

沒有關係，另外您剛剛提到第二年的時候，你說水利署會希望你們協助建立雲端預算跟開發人工智慧運用，這個具體來講是開發人工智慧的程式碼，是學界寫或者是你們寫或者是水利署寫？

主要是由水利署提供，看他們的業務單位討論，看有什麼需求來建立模式，我們會提供日後模式執行的環境。

你們有一個container的系統，然後一整包丟上來。

這個是第一個，我們把它當示範案好了，同樣的水利署資料如果是別的部會想要分析的話，也是循相同的模式嗎？就是直接把程式打包丟到你們這邊嗎？

水利署的資料本來就會提供在平台上讓其他單位介接。

假設GPU資源或者是其他資源的門檻，是任何人來都可以，然後1分鐘付多少錢，或者是參加這一個計畫的部會可以，以明年上半年來講？

目前是這一個計畫的部會，我們在數位建設也有其他的運算資源提供，到底那邊的營運模式怎麼樣，要到那邊才瞭解。

只要進這裡面的各個部會的互相資料都可以進行運算，對外面的是看其他的計畫？

看在這一個計畫裡面也會有跟產業介接的服務，看要如何合作。

最後是不是可以把你們這一些deliverable的哪一個月份，幫我們標註一下。

我們會在期程那邊報告。

我還是建議一下，國網跟經濟部那邊，幕僚是工研院跟資策會，請讓資料格式跟傳輸標準一致。

要看有多少的人用，也就是要統計一下API真正在每個月有哪一些API被使用，還有一個很重要的關鍵是，你的API不要出現軟體出問題，如果API被攻下來，所有的服務就斷了，所以API的資安很重要，所以為什麼聯發科在物聯網之後要做，他的資安團隊弄得很大，因為如果那一塊失手，很多服務就完了，所以API的服務要注意一下。

因為我們知道SensorThings有非常多的server，你們有挑特定的平台來測，或者是鎖定某一家或者是還在評估？

其實現在已經有在測一個。

可以講名字嗎？

現在投影片沒有，好像是德國的部分。

如果確定有先測哪一個的話，就像老師提醒資安的部分，因為其實之前都有一點歷史的，如果大一點的話，可能已經通過別的國家或者是別的地方資安的一些測試，當然我們自己在deploy的時候，自己也要再測一次。

今天有沒有要報告資安的部分？

沒有。調查表有送出去。

有確定資安是誰要來查驗，我們也會儘速通知大家，哪一些單位會來查驗。

請環保署報告。

政委、副執秘、李老師午安，我們就分項一、二來報告。

過去這一個規劃最主要的考量是，我們傳統的測站的時空解析度不夠，環境的應用、治理及資訊服務沒有辦法做到我們理想的目標，最近幾年因為有感測技術的提升，又有資料科學的技術發展，所以我們就結合了感測技術、資通訊科技、資料科學，希望透過廣布感測器在時間及空間的密度大幅提高後，可以再來針對環境的狀況能夠更細密及即時掌握，進一步治理環境，因此規劃了這一個空品物聯網的計畫。

報院的時候，就產生產業開展計畫來搭配的計畫，也就是分項二的計畫。這兩個計畫間的關係，橫向跟縱向分別說明，縱向的部分我們是從基礎的建構，在建構完之後進行場域布建，還有資料蒐集來作環保部門的一些治理應用外，對於最上面一層的開放及加值應用，也有做一些規劃。

首先環保署的計畫裡面，基礎的建構最主要是我們的驗證平台跟品保制度建立，還有整個物聯網感測資料中心的建置。這個建置好相關的布建，隨著感測技術成熟之後，空的感測器是為了污染密集高的地方或者是交通密集的都會區，我們做比較密集的布建。

水的部分也會有各種場域布建，主要是農地污染的部分，也就是跟民眾比較有感的食安布建。

最主要的應用是：空品的資訊服務，民眾會比較有感的時候我家附近的有感是如何，不會是10公里測站外的空品。

第二，時空解析度高之後，我們結合氣象的資料，也可以作比較精密的空品預報，讓資訊的服務，比如可以規劃下三小時或者是下六小時的每一個資訊知道的話，我們就可以做行程的規劃。

比如可以做呼吸歷程s的紀錄，可以知道空品如何，也可以在活動的建議更精準跟具體。

另一個，重污染天氣的時候，如何讓空品的高污染狀況是否能夠有減排管理加以減輕，我們也可以結合天氣的型態，來做精實的應變減排管理工作。因為解析度比較高，我們可以作比較精準的判斷。

這樣的資料我們會開放讓民眾加值應用，搭配這一些質保空間，各部會有相關的配套，比如在基礎建構的地方，最主要是要跟產業連結，也就是這一個過程中，有一些是臺灣本土化的技術跟產品生產，這一個地方包含了基礎處，PM2.5感測元件研發，科技部感測的研發，還有可以跟產業連結，並不是跟POS計畫，都會跟POB作相關的驗證服務，最後能夠有產業一定的效益。

產業布建的部分，當時的規劃是透過LASS布建模式由中科院資訊所來協助推廣佈建。

整個Milestone的部分，我們有逐年佈建的數量，我們會集中到中南部，水的部分會集中在農地污染的地方。

民眾有感的部分，事半功倍的地方，我們會詳加處理。

相關的產業開產計畫，各部會的工作事項就不再作說明。

主要的Milestone，就技術處的部分是PM2.5跟CO感測器，在AQI氣體感測器也會有不同成果的釋出，每一年有每一年的目標累積，環保署的部分會規劃1萬點，民間的部分也會超過1萬點以上的感測數據。

現在比較麻煩的是，這一些數據，我們希望透過預報解析度提升外，也會有所謂的AI人工智慧的技術引入，希望做相關數據資料的融合，來把民間一些準確度不高，來作動態調校，來作更精準且接近真實的資訊，並搭配國網中心的資料來提供民間應用。

我們現在把要建多少東西的效益來看，這只是工作，並不是效益，如果建完之後沒有後續的作業，其實是不會產生效益的。

我建議這一些Milestone的endpoint，不要說賺五百個或一千個說做完就做完，現在是加上這一些action的效益比較重要，這樣看起來是很難釐清花了什麼錢，而那個效益出現在什麼點，這樣ok吧？而不是把這個東西建完之後就自動完工，這個是不可能的，不然公司花很多錢來蓋工廠，這個工廠也是廢物，只是一直做資本攤提而已，這個是沒有用的，只是做了，但沒有後續的效益，我們看不出來，這個是看不出來的，因為後續效益是比較辛苦的，蓋東西比較沒有那麼辛苦，但後續效益是比較辛苦的。

舉一個例子：如果環保署的計畫，到最後在臺灣可以產生一個空品的SI公司，可以在東南亞設定一個移轉，我覺得這個就成功了，花了這麼大的一筆錢就算成功了。

我的意思是，像這樣的效益就很清楚，為什麼呢？因為代表你把硬體的部分跟環保署能夠建置的這一些軟體的部分，能夠重新打包成一個，讓業者進來介接走，東南亞的空污又是很嚴重的地方，所以我們就做產業輸出，這一個案子就非常成功，也就是從國土治理、老百姓的幸福都cover得到，這個是大案子的Milestone。

如何推到那裡，我不曉得，我只是個建議。

這個案子數字很大，只是建幾百個感測器，真的很沒感，再想一下。

我剛剛翻完幾個報告，像大家提的都是點，我不曉得有沒有誰會把它做一些整合，否則每一個計畫都自己建data、API，然後做一些大數據分析，再融入AI。

這個到底是不是民眾要的？我不曉得大家上班前會不會看空氣品質不好就不出門嗎？是不可能。

但是下山空氣品質不好就躲在山上，感覺這樣的情境不太容易，這樣的使用者不太多，我不能說沒有。

只是要如何比較多的使用者，因此這一個應用面不一定是我們自己要做，而是要如何call應用。

事實上日本有一個data，有一個API的介面，然後所有的服務都是call大家，從這一些data裡面，是有一組的，並不會每一個計畫都有自己的API，然後分析工具就是提供出來，讓所有應用程式的人可以直接呼叫。

好處是應用服務不用我們自己想，業者只要能賺到錢，就會自己想。

我上次去歐洲，我忘記哪一個國家，計程車上都會裝sensor，所以在全市跑，隨時抓的點就很多，台北市可能是上萬台計程車在路上、到處跑，每一個點都隨時可以抓到，類似這樣很多的服務，業者就會參與；也就是說，我們不用花很多錢，業者就會參與。

像很多應用的需求，民眾、社群都會得比我們多，我們可以建立讓應用服務那一層的需求端可以進來。

不曉得同仁有沒有要回應老師的詢問？

謝謝副執秘跟李老師的建議，原則上因為這個跟空品連結在一起，大家最有感的是空品的改善，但是其成因非常地多、複雜，並不是一個計畫就可以解決的，我的建議是看要如何呈現。

就像剛剛提到民眾有感的效益，也就是空品的改善。

像李老師提到資訊的服務與需求，這一個資料未來也都會是open的，包含感測資料基礎，也可以收容民間感測資料，所以基本上這一些資料也都會有open的，民間無窮的創意跟使用，我們相信也會發展出可能的應用。

我剛剛提到那一些應用，最主要是我們目前收到很多實際運動的人跟其他的人需求，也就是短時的預報對他們很重要，是否適合外出運動，他們care這一些點。

因為這個資訊是臨時想的，剛剛副執秘說到底民眾是否有感，我們是想這一些，而這一些資料就相關跨域的應用，也都要其他的部會來協助，像教育部在學校這邊的相關課程安排，或者是敏感兒相關的衛教工作，我想這一個部分都可以搭配。

要民眾有感的話，在有限的時間講出非常多的重點，我想可以的話，回到我們這一個計畫最主要的工作，也就是環境執法的改善，因此我們的重點會放在這裡。

其他創意的應用，我想可以作一些剛剛講質化文字的描述來帶到，但要很鉅細靡遺想到，我想就儘量提看看，然後再請我們的科辦長官指導。

你的核心價值主張其實是回到第4頁的打擊污染熱區跟裁處不法利得，也就是稽查員不增加的情況下，更多運用這一高時空的資料，可以打擊熱區，如果數字沒有達成，可能是做得太好，不敢排放污染；無論達到與否都是好事，這個都是好事，我會建議不要用那麼簡單的，也就是我們一定會打擊到幾家。

目前一個稽查員，我知道都非常忙，從接獲通知、確認到多少，那個工作時間，也就是實際的時數或者是經過不同單位協調到調取等等，一個追查到的機率及花的時間，你預測導入空氣跟感測器之後，會縮短多少時間，因此在任何的人力下會達成多少的效益，這個會比大家一定有這麼多污染，等你去稽查，相對來講比較有感。

執法的效率跟效益上可以多一些描述。

其實一個POC的計畫，我們也看到一個現象，我們感測到的一些特徵，剛好跟民眾陳請的時間點與空間的分布、特徵幾乎是相似的，大概有七至八成的相似。

因此我們應用到那邊，民眾的陳情會有所感覺。

這樣講就非常好，請繼續。

唐政委、葉副執秘、李老師、各位先生、女士，接下來由中央氣象局報告，主要是針對臺灣地區海嘯、火山及地震這三個天然的災害希望能夠提出預警，其實目前都能夠提出預警，但這一個計畫是要縮短預警的時間。

先放到大屯火山的展示，有幾個原因，第一個是已被證實活火山，而且是鄰近兩個電廠，大家對於大屯火山的活動非常關心。

另外一個重點是，明年7月Milestone就會建置完成，所以五項計畫中第一個是最早可以完成的就是這一個工作，因此可以擺在第一年的亮點，第二年以後會有其他的亮點。

五項的計畫很快再看一下，錢花最多的是海纜擴建，目前有115公里，希望再延長到515公里，至少再增加6座測站，對南部地區跟北部地區的海嘯可以提供更多預警的時間。

另外，地震的觀測系統，可能設備要升級，資料解析度及品質要提升。

在大屯火山觀測，剛剛有講過，明年6月就會完成。

另外我們要建置資料的管理系統，以及調查盲斷層，盲斷層是未來地震預測的重要模型。

今年年底海纜會擬訂規格，明年6月就會招標跟決標，明年就會進行鋪設路線的調查。另外一個登陸點，枋山也已經考察完畢，枋山剛好有兩個國際海纜要退役，時間點剛好可以補上去。

升級地震與地球物理觀測系統，我們在今年年底地表強震儀、地下井的地震設備及GNSS儀器就會完成決標，明年就會安裝完成。

加強大屯火山的觀測設備，我剛剛有提到一個亮點，也就是火山展示室，明年6月就會完成，年底會有三篇最新的研究報告。

資料庫的管理系統，現在橫向擴展網路儲存設備、多媒體電視牆匯流系統，今年底就會建構完成，明年底的虛擬化系統，也會建置完成，我們隨時可以開一些虛擬的，大概可以開到一百套設備。

有關於盲斷層方面，今年底會完成研究計畫的招標，明年底會有兩篇盲斷層的部分。

最重要效益的部分，我們預警的時間是可以爭取十至二十秒的地震預警，海嘯是增加二十至三十分鐘的預警。其實海嘯有十分鐘的預警，傷亡人數可以減少90％。另外，海陸的聯合觀測，可以把強的預警跟東部外海的地震可以縮短到十秒內，盲區可以縮小到三十公里。

在大屯火山的觀測，因為鄰近台北都會區及兩座電廠，掌握情形，有利於對北臺灣的影響。

其實火山要爆發前，我們可以提供幾十天的預警時間，火山可以提供的天數是幾十天來算，海嘯大概可以提早十分鐘至三十分鐘的預警時間，地震是幾秒鐘預警時間。

另外，我們要建置地震跟地球物理資料的關聯系統，我們會開放地震跟地球物理的資料對產業進行大數據的分析，以引進民間的力量來進行跨域結合，以促進國內產業防救災的發展。

比如地震密集帶的調查，也就是孕震構造跟盲斷層的研究，以上。

幾個建議：

第一個，Milestone不要寫委託研究案幾個，老闆不會care，他會說這個是你工作項目，不是你達成的東西。

而是做這一些東西會產生什麼效益，這個是長官比較care的，也就是action item不是重點，而是後面產生的才是重點。

第二個，剛剛提到整體效益，看起來都非常重要，但似乎少了一個連動，我舉一個例子，像大屯火山對台北都會區跟核能電廠是非常重要的，但這個東西我們要如何讓它連動起來，也就是台北市政府跟台北市民怎麼知道做了這一件事對他是有效的，也就是透過現在地震速報或者是火山怎麼樣，又或者是核能電廠要如何連動，現在核能電廠連動應該是被動的等等，也就是有直接效益，並不是做這一件事有效益，而不知道如何連在一起。因此這裡面有幾個項目，其實是沒有連結線的。

因為您剛剛提到上網人數減少90％，相比後面是有一個模型，我不是在講大屯火山，我是在講別的，海嘯。

如果有一個模型的話，我會建議直接把它預計，也就是建置這個之前，可能會有多大規模的傷亡或者是損失，比如海嘯的例子，有了就減少90％，變成有多少的損失，你跟地方政府中間就很容易去講說有這一個關係，所以會透過什麼方式收到，這個我覺得是很好的提醒。

另外一件事，先讓大家明確瞭解到有這個之後，預警的時間有多長，充分疏散，不至於動搖國本的情況下，其實這樣子就非常有感。其實有感跟無感就是從地震這邊來的，不會有人覺得不重要，但有了之後會有多重要，這個部分可以再多表示一些，這個是另外一件事，謝謝。

如果有要回應就回應，不然就是調整一下簡報就好。

我再補充一下，我舉一個例子，像唐政委講的，因為這個是非常基礎的，也就是外界很難說有很強烈地感覺，我還是建議一下。

像剛剛講到海嘯這一件事，是不是應該把這個東西變成3D科普的動畫來教育老百姓，不能說從日常生活或者是教育面下去讓這一個東西有效果，也就是讓大家說拍VR，然後就可以知道海嘯是1秒、10秒來會長什麼樣，結合臺灣的地形跟地貌，這個就非常有感，這個要從另外一個角度來看。

另外一個是，既然對台北市是有效的，台北市是否認知這一件事？這一個計畫要連結台北市，因為地利他，所以麻煩你去連結台北市（及新北市），那麼台北市就會連結我們對他市民的貢獻，不然我們只是講，而台北市沒有參與，就沒有貢獻，因此我的建議是邀請台北市來參與這一個部分，也就是台北、新北等幾個地方，謝謝。

剛剛唐政委提醒得非常好，日本就是受到海嘯及火山的地震威脅非常大，而且他們幾乎常常有海嘯，我們有非常多日本的資料，我們整理一些讓民眾有感的影片給大家看一下。

唐政委、葉副執秘及李老師好，我這邊是國家地震工程研究中心報告，我是針對分項四、複合式地震速報服務的分項計畫（說明）。

複合式地震速報計畫，主要是把地震的速報系統建立起來，包含訊息上游、傳遞中游及應用範例來做成產業化。工作重點主要是上游的建置，包含主要是在做現地速報的建置，我們場勘了很多的點，為了選擇依照斷層的分布跟區域的分布，把點位找出來，我們去現場場勘，我們也把現地的位置去做了一次跟選點，希望選的點的環境是比較安靜的，可以提供比較精密量測的數據。以上這一些都是工作。

我們可以呈現亮點的時間約略是明年年底，如果把上游的資訊做好以後，大概在明年中以後，我們就會開始做地震速報的應用式範例，明年開始我們就會逐步去找廠商，去做一些地震速報的應用，就像日本現在已經有很多不同的應用，在廣播、手機、手錶及電視，諸如此類的，我們希望跟多元廠商、通訊方式去做，我會希望明年開始做第一個案例，我們會先從公部門的案子先做。

在明年上半年之前，我們主要的工作內容是從上游資訊、中游平台為主，我們會在明年中開始做好，然後再建置。

兩個建議：

第一，跟中央氣象局這部分的訊號有沒有連結？

有。

這個非常重要，最後是以中央氣象局為準。

另外，使用者跟產業加值的部分，這個對我們的工作來講是非常重要的一件事，產業加值的部分有沒有比較重要的action，舉一個例子，也就是跟台積電所有的場，直接透過這一個模式來介接？也就是透過你的機台來接訊號了？是不是民眾比較有感的點來當作切入點？

台積電目前已經介接了，在竹科、中科及南科已經建了三套系統，連結五千個機台。聯電我們都已經場勘了，但那都是獨立案件，都委託我們的基礎廠商去做。

高鐵的部分，我們預計年底也會開始做這一個案子。高鐵的案子有獨立的偵測系統，我們希望跟前瞻計畫有一些連結，我們希望大家的資訊可以交換，讓你的訊息可以更快速、精準，這個部分我們還需要再跟高鐵聯繫，我們希望可以連起來，畢竟我們是同一個團隊在做。

像對臺灣經濟活動產業比較重要的部分，應該當作優先的切入點，這麼大規模的資訊在回流的時候，比單一的現地型有效果。

其實這一個是大家都用得到的服務，當然特別重要的一些點，我們之前就像你說已經設點了，這個是一件事，但因為我們從最一開始，也就是這一個核定版計畫，也就是要把上中下游的產業鏈帶起來，不能只是我們在這邊應用示範而沒有帶出去。

當你把API做好以後，如果機關自己把應用示範得太好，然後一直維運，就會被說與民爭利；反過來，完全不做運用，說好讓私人廠商來做，又會被說有圖利之虞，這兩頂帽子，永遠都有一頂適用。

要解決這個問題，在推展的時候，我想比較是拋磚引玉的想法。一開始做的這種應用示範範例的建置，可能在建置的過程中，像我們在這樣的checkpoint的會報或者是逐字稿，先讓大家知道有這一件事，我們會用哪一些等等，當然最好的情況是在學校或者是教育的用途，他們甚至會同意把這一個程式本身都開源出來，等於讓業界都知道這樣子做，再拿去做研發的時候，成本就降低。

如果基本上API跟源碼都是open的，外面不會說圖利或者是與民爭利，這個等於是我們做示範的運用方法，之後要用的人再改做私有的做法，這個是比較可行的。

當然，如果應用的site本身是私部門或者是有自己的一些點位的機密，又或者是通訊協定要自己做，那當然不可能open source，但至少底下這個API是開放的。

我覺得如果守住這一個，比較有可能把上、中、下游整合起來，大概是這樣子。

主席、葉副執秘、李到時及各位先進大家好，我是針對分項五「災害情資產業建置」來作說明，這一個計畫有四項主要的工作，第一項剛剛李老師有提到要看國發會的標準。

我們當時主要內政部資訊中心，因為他們對於感測網的一些基本部分，尤其是民生性的感測網，像水位跟雨量，之前已經有做基礎的study，這一次也是跟民生公共議題有關的，像空品或者是水資源又或者地震這一類的，我們當時跟部會協商的時候，這一個部分就會以OGC的API，已經follow內政部資訊中心，有對於雨量跟CCTV這一個部分，所以我們第一個工作項目就是希望民生的sensor這一個部分，我們希望在這一次的計畫，能夠用API的這一個方式，來建置起來，這個是災防中心跟國網會協助這一個部分。

第二個部分，有關於民生災害示警的部分，這一次也是民生公共物聯網的部會都會產製相關的示警，我們在示警於之前就已經有導入CAD的模式，像這一次會拓展到地方政府所使用跟民生比較相關的，像災害時的例如水閘門關閉，又或者是開放一些地區的紅黃線停車，這一個部分地方政府會加入。

在國際間對於示警的部分，其實已經結合成一個所謂緊急資料交換的標準，所以簡稱是EDXL的標準，其實就把示警納入。這一次我們會把整個相關的緊急資料標準的這個部分，跟國際間導入。

第三個，災防中心跟國網協助，也就是進行Data Hub的產業來介接，跟整個計畫相關的管理部分。主要在今年第一期的查核，主要會把這一些相關感測的環境格式都會立訂清楚。

第一期的Data Hub預計在新竹國網的部分，剛剛國網有報告，第一期的Data Hub就會成熟。Data Hub是採三地的，所以以後是高可用性，先在新竹進行，明年會第一期建置完成，我們之後會持續進行在宜蘭地、台中地的建置。

除了各部會提供外，還有一些部會像傳統的雨量站的一些資料進來的話，或者是CCTV進來的話，我們都會協助導入Sensor Things API的部分，在Data Hub來作資料的交換。

在第一期的部分，我們在年底都會把資料完成，以上是分項說明。

感謝。

EDXL有八項或九項，全部都用EDXL，然後全部都做嗎？

第一期會實做四項，包含situation的部分。CAP比較成熟，第一個部分也會一併加入，其他的我們可能會在第二期、第三期的時候逐漸加入。

就是把成熟的部分先做，他們還在測試的之後再說，但是就是以EDXL family為基礎。

在簡報裡面可能稍微加一下，加一些用中文講很容易講的，也就是有哪一些事會進入緊急災害的介接，我想這樣子比較容易看得懂，尤其是對縮寫比較不熟悉的朋友。

一個建議：像這一種東西跟產業的活動很重要，但是我們這麼大的資料慢慢匯流之後，我們沒有辦法看到金融保險或者是農業這一些的互動到底是什麼。

這一個部分是計畫比較弱的部分，也就是跟產業的介接。

目前的使用者端也就是科技部會有一個智慧園區，我們會跟三個園區等於是我們的使用者端，不過的確跟產業的部分，目前平台如何跟產業來做更好的成果效益，現在還沒有那麼成型。

是不是可以真的好好坐下來問部會或者是公協會來討論這樣的事，這一些資訊對他們來講哪一些是有效、沒效，做到這樣的話，但對產業都沒有用，我們真的太對不起自己的工作了，這個就差最後一哩路而已，希望把這一塊拉出來。

我們目前11月2日有請產業防災協會來作溝通，如果有一些進一步的溝通，如果之後需要葉哲良執秘協助的話，再請葉哲良執秘指導。

跟您請教，像你們那邊有一個災情情資，這個跟國網剛剛所提的是同一件事，是不是？就是國網最早報告，也就是做Data Hub的平台，是不是同一個平台？

是。

所以各分項的所有資料就是要匯入這一個平台，各分項不用再建自己的平台、再建資料，我看後面還有一個計畫，像消防署也自己做API，理論上應該就不需要吧！也就是同一組都是API，而資料就進到這一個平台，也就是來國網的那一張圖，對不對？

對。

所以應該要這樣，這樣大家不會花很多硬體的錢來做系統，又做很多虛擬化，我看每一個計畫都這樣的話，這樣就有一點浪費了。

國網或者是放在中心，也就是試著要把資弄下來，這樣API發展的時程可能要更早，因為要讓人家做應用，結果到明年12月才把API做完，做完之後，這一個計畫看不到服務，一般來說是資料出去的時候，API就要同時準備好，這樣大家就可以用。

所以我們的查核點比較不耗用，也就是兩項API模組，你做得不好，可能要一百項，可能更差，所以像素越多可能沒有關聯性。

像農業很多應用，或者金融、保險等等，他們對於這一些資訊，搞不好會很需要。那一天碰到高董事長，他們就說要用好幾倍的錢去收購香蕉，天氣好的時候，忽然產量過剩，天氣不好就很貴，也就是沒有預估個規劃，大家就亂種，像這一些情資也可以提供給農委會，這個是內部自己需求的規劃。

像之前做氣象的人，他們賣給金融單位去做期貨，代表應用面滿多元，不只在放在跟食品等等的需求，包含進出口很多的資料。

所以我會建議有一些API是不是可以更早完成，後面就會有應用服務。

好，謝謝老師。

像上次有一個訊息電信網，因為你要通知民眾，也就是跟其他的服務如何間接，因為上次是中華出問題（笑），大家都記得在測試訊號就沒有收到，因為後面底層是在電信服務商或者是其他的有線電視，這一些串接的服務，也要讓他們知道。

主席、各位長官，消防署接下來報告的是防救災系統的整合。

其實我們這邊系統的整合，也就是包含了防災跟救災的部分，我們接下來四張投影片會針對第三張投影片，也就是106年度在年底的工作項目，其實後面三張投影片也會在107年的6月跟12月。

我們106年年度12月的部分，包括了一些招標的前置工作，目前雙方的作業正在進行當中，也就是在公告。

我們主要的建置是招標作業自106年至109年，其實在防救災的資訊系統整合部分，其實主要的是針對我們的EMIC系統來作精進、優化的2.0建置，災害情報站也會再就災害情報站2.0來作優化。

除了前面兩項是屬於技術建置的部分，「3」、「4」是屬於推廣及規劃的部分，包含我們的數位教材及推廣的作業，接下來是網站平台的演練建置跟推廣的招標作業。

我們預計要做放在知識館、編撰防災教材，希望透過社群的推播作推廣的動作，在演練的部分，我們希望可以加強民眾的參與，提供互動跟學習分享的體驗平台。

第五個工作項目完成整合水電民生的部分，消防署會與NCDR合作，也就是做圖資圖台的合併動作。

107年度我們預期會在汛期之前的5月提供一個亮點，而這邊的亮點是希望能夠提供一站服務的民眾版，災害情報站是消防署這邊所建置的。因為其實目前國家的政策是希望能夠將所有的服務能夠整合、能夠提供給民眾單一入口的方式，拿到他要的資訊。

所以我們在明年5月汛期之前的時候，這一邊的亮點是希望能夠提供民眾豐富圖資化的視覺資訊，我們希望可以把相關的圖例能夠清楚顯示單一圖層，希望可以看到要的災害資訊或者是交通的水電資訊。

目前可以提供的資訊，包含了民生資訊、颱風路徑這一些，我們希望可以開放更多的資訊，也許地震、交通、淹水、海嘯等資訊，都可以整合到一站式的圖台，讓民眾可以更容易查詢。

在明年的部分，除了NCDR可以提供道路停水及電信的地圖服務部分。另外，我們在剛剛提到的規劃推廣的部分，防災知識推廣演練這邊，我們希望可以將防颱、防震的知識，利用網路推播活動，能夠達到讓民眾去瞭解這一些防颱、防震的知識。

我們預計會建立一個防災教育館或者是跟科博館合作，希望用AR或者是MR的方式，讓民眾可以透過擴增實境可以更容易瞭解我們這一些知識推廣。

在之前的會議，唐政委希望我們可以針對K12的目標來作設計的動作，消防署有召開會議來討論，也有邀請專家來作評估的工作。K12是希望由教育部，其比較能夠focus群眾的口味，我們這邊會主要針對 民眾的部分來作推廣，教材以針對民眾的角度去設計。

在107年度的部分，我們在防救災系統的部分，我們希望能夠建立資料的平台，能夠將所需要的Open Data，在EMIC有相當多的通報表及避難收容的資訊，我們希望能夠集合在一起，其實比如以民眾業界的創意跟未來開發發展是無窮的，我們希望把這一些資料開放出去，並提供給Open API，讓大家拿到的時候，可以做後續的設計跟創意的發展。要開放哪一些Open Data跟API，我們會邀請專家學者來瞭解他們所需要的未來資訊到底包括哪一些。

第一個是要建置數據匯流的平台，我們未來要跟NCDR整合，我們這邊會以防救災為基底提供資訊的服務，可以強化資料平台交換的，以上報告。

幾個建議：

災害情報的這一件事，民眾的使用度不是很高，原因其實很簡單，因為是政府做的，使用度一向很差，很久才會更新一次，沒有預算就不會動。

所以G2C的這一件事，政府來做的非法定的G2C，政府來做好嗎？其實我一直很疑惑這一件事，我們是不是在非法令的部分，是不是應該找外面的社群或者是企業來做這樣的事情才是對的？因為不會更新，那就沒有辦法符合群眾要的需求，老百姓可能這樣看比較舒服，你就設計成那樣子，那就不舒服，因此就不要用。

所以這一件事，是不是回去再想想看，我們要花多少的力氣來建這一件事，然後沒有人用，這個效度不好，我們是不是應該去找其他的業者或者是社群來做這樣的事，我們協助他來做，我們只維持一個基本款就好了，其他的我們就說連結部位有很多人在用，這個很重要，這個是我的第一個建議。

第二個，李老師講說Open API的這一件事，各個部會都說他的頻寬不足，沒有辦法介接等等，這裡又做Open API，等一下NCDR那邊跟你的API不一樣的話，這個會發生什麼事？這個問題很大，所以為何要把這一些東西都統合在同一個單位下，就是大家都同一個系統，如果今天要開Open API沒有關係，最好跟兩個單位一模一樣，所以你們一定要協調好Open API跟其他兩個單位是一致的，即使要開也沒有關係，至少是一致的，不管誰是備援、誰是主動的，這沒有關係。

我們之前的默契是國網要放一份，如果有不同來源，有相同用途，請大家要找同樣的Data model，現在看起來找出來是Sensor Things跟EDXL，當然我們知道目前EMIC出來的資料格式，當然以我的理解都不是這一些，所以它中間還是要有一個資料格式轉換的工作，會有一些清洗的工作，其實那時也都有包在這一個計畫裡面，我如果沒有記錯的話。

我的意思是不只是要邀專家學者內部的討論，我們的整合也要做好。

我很同意剛剛葉哲良的意見，我們把這一個公版，本來是照顧類似地方政府的需求，但民眾也不一定不能滿足到一個程度，但再過去，可能就是我們把我們的程式碼或者是做的方式都公開，讓民間自己要做這一個的成本儘量降低，我們就可以說看不順眼就自己去做，這一句話才講得出來。

我記得以前都是EMIC開一個私人的API，網頁又自己去串接等等，民間光是逆向工程就要花非常多的力氣，根本不可能做自己的版本，這個部分再麻煩多留意，謝謝。

我們再討論一下是不是取得平衡，因為我們的確是要達到所有民眾的標準、想要的方式，其實是比較難的，我們就看製作基本款、基本功能，我們後續也是有這一個idea，我們才把資料來作開放的方式，讓其他的加值，也許加值之後回過頭來也可以利用這一些加值的部分再嵌入我們的網站，謝謝。

主席、各位長官，接下來就由水利署來報告物聯網。

我們一開始規劃的計畫亮點是，因為額有關於水的資訊，基本上是分散很多的單位，我們希望透過水資源物聯網的平台，我們希望針對水利署內部的相關資料先來作整合，之後再作外部資料的介接。

這一些資訊會包含一般我們所用的用水、蓄水跟觀測量，還有水的預報產品。另外在這一個計畫裡面我們新增一些觀測圖，我們希望透過這一些資料來作資訊整合以後，最後才到國網中心，我們會有一個物聯網的API提供給外界使用。

最重要的是，我們希望透過資訊的整合之後，我們如何讓水的調度變得更有效率，這個是我們另外一個重點。

另外，因為農業用水佔整個用水的70％，所以怎麼樣去提升農業用水的效率對於水資源扮演一個非常重要的角色，因此我們特別與農委會合作，在桃園、石門、新竹、家南、高雄水利會會進行一個精密灌溉的實驗。

我們會針對攝影機、自動閘門的控制，瞭解天間的蓄水量，對於灌溉用水的效率提升，節省水資源的供應。

所以這一個計畫大概有幾個主軸，第一個是水資源物聯網的部分，一開始我們會建立IaaS、Paas及Saas，還有一個是水資源的調度，就是利用我們這一些資料來作加值運用，提升整個用水的效率。接著是節省精密灌溉節水，其實這三個主要的目的，就是要讓整個用水的效率提高。

另外一個基本上是從防汛的角度來看，我們除了水資源的調度以外，還有有關於閥門的安全。防汛的部分，我們會針對這一個地方來作河川觀測、流量的觀測跟淹水預報跟演算，也就是事實上在水利署自己對外有一個「行動水型APP」，使用的人數相對也滿多的，我們希望未來有關於防洪安全即時的警戒資料跟預報的資料，都可以透過這個，讓民眾可以直接使用。

所以未來這一個計畫大概有兩個主要的重點：第一個是有關於水資源的節省；第二個是有關於防汛的安全。以上說明。

這個Milestone前幾天看到的時候，我真的不太懂，我要理解，你在說明的時候，我才有辦法理解，因此對長官來講……我都看不懂，長官一定看不懂，所以麻煩一下。

像水資源跟效度，這一定要定義清楚。我舉一個例子：像ZARA的這一家成衣廠，為何要導入IFRD的技術，原因是要打擊庫存，實際的效益是多少？導入之後的庫存量降低了8％，間接的人工降低了，也就是處理這一些庫存的人工，大概降低了一成多，這就是效益。所以如果你說導入系統之後，水的有效資源會提高多少，其實是會被評估出來的，我們才有辦法做這樣的事情。

人家為了做這一些監測網是某一個目的，因此我還是希望可以把這一個稍微釐清一點，就是重新再整理一下，也就是效益的點在哪裡，謝謝。

我看到最近很多計畫，每一個政府雲的建議都建IaaS、PaaS，過來國發會一開始希望政府有一個IaaS就可以了，美國這麼大就只有一個IaaS，臺灣卻建了十幾個IaaS跟PaaS，感覺怪怪的。

因為一個案子可以支持很多，像微軟、AMAZON事實上就是一個IaaS，就是很多備援的地方，互相作資料儲存，但是這一個計畫又要自建IaaS。

假設這是前瞻計畫，有很多分項出去之後，會不會多出很多IaaS、PaaS出來？理論上IaaS是一個，PaaS可能幾個，SaaS要很多，我們像都是一比一地建，感覺怪怪的（笑）。

不過這個是用國網的吧！如果我沒有記錯的話。

跟主席報告，其實是這樣的，有部分是自建、有部分是用國網的。為何會需要這一個建案？其實目前來講，像Azure或中華電信都有提供這樣的服務。

但我們現在在思考的是，等到成本降低到比我們自建的部分還便宜，就會用他們的；但目前來講我們評估過，還是自建的比較便宜。

國網會比較貴？

國網會是規劃成我們的備援。

國網自己本身就要有三個備援中心，因為會分散儲存，所以根本不需要自己做備援，假設國網做得好，拿了很多預算，理論上就不會只會一個site，至少在高雄、台南的南國網……像中華的HiCloud，除了台北，台中、高雄都有備援中心。

事實上上了IaaS，事實上資料不可能不見，如果大家都這樣做，代表國網的服務提供得不夠好，而大家不信任。

國網可不可以回應一下？

國網是不是做得不夠好？

不好意思，我們之前有跟水利署資訊室有稍微討論過，他們因為業務使用的需求，所以希望在單位的內部有緊密配合的部分，會由資訊室來作協助。

我們會做系統的備援，如果他們使用量比較大的時候，或者資料保存的部分，他們會希望用國網的資源，因為整個應用端還是會希望跟業務單位討論，他們也會建一套，他們是這樣規劃的，謝謝。

其實我一直以為這個計畫在一開始，就說不要這樣做了（笑）。

像EMIC本來就有一個東西放在那邊，所以他慢慢移到國網，這個是說得通的。但現在沒有，而是你們自己要多一個平台，我不是很確定是不是這個情況？

我們有一部分是跟國網合作，所以物聯網的部分，就資料傳輸的部分分成兩項，一部分是有關於署裡面的小平台，另外一部分是傳到國網那邊去。

因為蒐集的運用，基本上署裡面還是有需要，算是互為備援。另外，我們也需要快速且有效，所以基於業務上的原因，因此做這樣的考量。

建議把那幾句話加在簡報上，不然所有的人聽到「建立雲端數據中心」，應該都會跟我們三個人一樣的反應（笑）。

這樣的回答，我覺得國網的雲端建置有一點不太完備。

你看微軟，其實用得人根本不知道資料在哪裡，架在水利署的伺服器或國網伺服器或Google伺服器，業者是不知道的，真的不會比較慢，搞不好放在自己家裡是最慢的。

你看Google的速度快到不行，因為有足夠的人力維持，所以服務不會中斷，理論上雲端服務是要99.999％，你自己做的話，很難達到90％以上。：

我們發現成本降不下來，尤其是水災啟動以後，我們要付太多的費用。

理論上不應該比較貴啊！這麼多人共用，你的硬體是大家分享用的，而且你又拿國家預算在建置。

那就是國網要關掉了（笑）。

這個聽起來又很奇怪。

你剛剛說水災出現的時候，就是你需要彈性開好幾台虛擬機或者是好幾百台虛擬機的時候，在自動延展的情況下，國網會收非常多錢？

我們自己是用自己的設備機去run這一些，前瞻的部分我們會跟國網來作長期的合作。

到底差多少？

自建應該會成本節省超過3、40％以上，所以目前自建還是比較便宜。舉微軟Azure為例，其實我們那時也做過研商，但他們的租用，其實費用也相當地可觀，就目前來講，我們那樣的負擔是滿沉重的，因此我們認為還是以目前這一個方式來擴充，以上補充。

瞭解，我接下來會跟國網再多瞭解一下建置的規劃。這不是這一場會議可以處理的，但很高興有這一個訊號（笑）。

我想問一個非常細節的問題。你在簡報最前面有各個不同的來源，對不對？就是有包含氣象局、水利署之類的，我第一次把公共民生物聯網、直轄市跟縣市市長分享的時候，台南市當時問了一個問題，沿岸分別是氣象局的將軍潮尾站、水利署的安南跟港研所技術研究中心在安平，像安平根本沒有在氣象局的網站上，因為等於是交通部的，完全不同體系的東西。

像這樣是在這一個系統架構裡面，或者是要特別像外交關係一樣，再跟交通部談？

其實我們現在是跟氣象局合在一起的，所有的資料都有送到氣象局，但您剛剛提到港研中心，他們的資料跟我們的與氣象局不太一樣，所以一般來講都會使用，原則上我們是依照氣象局在看點的位置在使用，所以港研中心用得比較少，他們有自己的系統，每六分鐘就tag一筆資料，我們大概是十分鐘，所以一直沒有辦法連在一起，我們不會tag他們的資料。

簡單來講，你覺得沒有到你的資料品質之類的，所以不放在這一個平台上，如果他的品質跟你相同的，你才會接進來，是這個意思嗎？

資料處理系統有訂一個規範，其實我們的意思是，資料全部會進到氣象局裡面，所以氣象局有一個品管，他們也會tag感元中心資料，跟我們要的每十分鐘一筆筆資料還要另外處理，所以原則上在防災上不會運用這一塊。

可是你剛剛講的第二句話不太一樣，你的意思是氣象局有這個資料，只是不公開出來？

會帶進去，但是我們在做防災的時候，不取這一個資料。

因為這個計畫不完全只是防救災用的，所以只要資料不是錯的，難道不是有資料比沒資料好嗎？

因為港研中心觀測站通常是為了特殊目的去做的，我們跟氣象局已經談好，所以原則上可以cover的地方，我們現在跟氣象局也在談，包括雨量站，如果可以互相cover，也許我們站要廢掉，是這樣的情況。

意思就是少那個點沒差？

對。

不曉得兩位還有沒有指教？

我也知道十個工作天有一點趕，但大家在簡報過程中，也很感謝兩位的指教，其實都有講一些，也就是如何讓內容更讓大家瞭解，之前各位互相討論過，但這一次是綜合性的報告，我們之後要核定成一本出去的感覺，我想排版都不用再修，但剛剛提到字樣上或者是里程碑或者是效益上要調整的部分，麻煩在逐字稿修訂的工作天之後，麻煩出一版改過的簡報，如果你覺得很棒不用再改，就不用再改，我們就當作院長巡迴的參考。

這個工作真的很有意義，但多有意義，接下來就要讓各界，包含地方政府、廠商及社群都要知道的事，這一件事就希望各位一直保持著隨時都可以用白話文說明的部分，謝謝大家。

剛剛政委講到最後一個，大家修正Milestone，有三個亮點，分別是質化指標、量化指標，量化指標是以院跟部的層級來寫，就這樣，麻煩，謝謝。