大家好，我們一向準時開始。

之前我們對系統整合的這個題目，其實開過相當多次會，包含跟NCDR、消防署、廠商開過一些預備會議，也把逐字稿公開了，也有社群朋友們看了之後覺得我們事實上以本來的分工架構做得滿好的。分工是一回事，今天是談如何整合的工作。

整合的endpoint已經在前幾次的會前會開出來了，書面資料在我這邊，看到消防署對於他們能夠開出來的這一些endpoint，以及災防中心介接進來的話，給予一般大眾的話，還需要哪一些支援，這一些事是已經有書面的討論。

其他的部分包含台水、台電或者是路段資料的話，大家手上有什麼資訊就分享這個資訊，但是我自己這邊是我上次會後自己有寫信給台水，問他們的資料可用性之類的，他們說正在調資料，他們有一些舊的系統是符合我們的要求，但後來沒有維護了。

所以我們不勉強，手上沒有的資料就先沒有，大家有的就先分享一下，請消防署。

各位發言之前，請說一下怎麼稱呼，謝謝。

消防署資訊室報告，首先是針對2月14日會議詢問的一些議題，我們這邊有做一些整理，第一個是EMIC網頁資料何者為自行產出的部分？抱歉，因為我這邊是只針對結構性的資料整理，其實還有一些資料不只這一些，像有一些是我們的處置報告，還有一些相關的資料，我這邊是沒有放上來的。我們自行產出了八項資料，詳如附件1。

其他單位提供的資料是計有十二項，其中介接環保署CDX的部分有九項，公路總局有兩項，人事行政總處這邊，我們原先有跟他們連結，後來資料有一點誤差，我們直接改用連結的方式，直接連結到人事行政總處停班停課的網頁。

第二，是否有提供Open Data的部分？環保署CDX總共開放到Open Data的部分計有十項，但上面介接環保署CDX9項裡，有兩項在Open Data裡面。相關的彙整資料如附件2。

第三，這邊特別要講的是，通報表的部分（附件1）有電力、自來水管、天然氣及電信，這個部分我們分別是用帶入參數。

你們是同樣的query endpoint？

對，雖然是從EMIC去介接出來的，但是相關的資料是由各事業單位去作填報的動作，這邊先作一個說明。然後再回到剛剛的word檔。

再來，我們有提到的是，這一些資料有哪一些沒有放到Open Data，可是有沒有網址的部分，這個部分我們可能還要再洽相關提供單位再來彙整，這個部分有一點來不及提供。

澄清一下，意思是在你們自行產出這一些部分，我這邊可以看到的是，這五個報告表是不同來源所填入的。

這理論上有各自的Open Data，然後你們還不確定各自是否能轉成Open Data？

不是。

還是endpoint本身能不能轉成Open Data？

這個資料可以轉。我們比較擔心的是，以颱風為例好了，通報表為例，因為通報表隨著颱風的進展，事業單位會一直填報，我們怕的是因為隨時提供這一份資訊，可是在做災情查證的時候，數據一直在變，會讓民眾覺得很奇怪，前面的資料跟後面的資料怎麼會有一些誤差，這個是目前要顧慮的地方。

所謂的前後資料不同是新增的而已？或者是連舊的資料一起取消或者是改變？

比如沒有停水停電好了，可能之前有一些誤報，我是說那一些數據會有一些變動。

不好意思，消防署補充一下，請幫我投影EXCEL表。我們其實是從事業單位填報的通報表填進來的資料，理論上從中央災害應變中心的角度去發通報表的Open Data，理論上是可以的，因為我們是有時間產出，我們是從災害應變中心，這個部分我們這個部分會努力，我們會提到Open Data，上面並寫時間，是什麼時間的第幾報。

另外一個部分，這裡面有很多不管是水、電或者是相關瓦斯的統計資料，因為剛好今天我們也找了台水、北水跟台電公司來開會，有一些資料他們自己有自作，他們會有一些動態資料的不同，這個部分我們在今天的會議，我們也請他們，比如這一個時間點停水是多少，他自己放到Open Data，所以有兩個部分的區隔，一個部分是事業單位目前自己現在的資料，包括統計資料、raw data，到底什麼地方停水、停電，這個部分都有要求他們可以Open Data，目前看起來台水、台電都可以。

這個通報表的部分，我們會之後處理Open Data，也就是每一報資料就出去。

每一報出去，有固定的間隔嗎？

三個小時。

那有可能原本停水，下一報就不停水了，不管原本是誤報或者是真的。

對，等於是未來在資料公開的部分及我們在詮釋資料，我們就加強說明一下這個是什麼時間點，可能會有的狀況，我們會去加強。

然後我們把後續所有相關統包表的資料，從應變中心的角度去提供給Open Data。

因為這兩個性質是不同的，一個是有固定時間間隔、固定格式，已經集成過，而且是他們做過綜整之後才到你們這邊。一個是raw data，也許人都沒有看過，是sensor自己給出來的，最好的情況是兩個都有，但沒有的情況下，至少有你們這個，所以就是說並不是我們能夠協調到他們可以釋出raw data，這一個災情通報就不需要Open Data，我覺得是分開看的。所以這一個東西目前轉成Open Data，不管是用服務形式或者是批次下載形式放到data.gov.tw的描述資料上面，你們有沒有任何技術上或者是支援上的協助，或者是現有就可以做了？

這個我們署裡面就可以處理了。

什麼時候可以處理？

我們會跟廠商聯繫，我們是希望在今年汛期前就把這個準備好，這個資料有應變中心開設的時候才會有，我們今年汛期之前把它準備好。

瞭解，謝謝。

接著是EMIC登打系統可否開出可寫入API？目前我們系統上已經提供災情介接API供119、1999，還有新北市、台北市自建EMIC，還有企業災情案件的匯入。

另外，因為現在目前EMIC裡面有十六項子功能，所以我們可能在下一個禮拜，我們預計在下個禮拜會跟我們的業務單位再做一個確認，看哪一些東西是可以盤點出來，也就是哪一些東西需要提供可登打的API。

這邊需要的意思有兩個：一個是你們現在本來就已經有外界可登打的界面，甚至包含我們上次看到民眾在可開放的縣市可登打，那個是一部分；另外一個部分是，你們覺得這個子功能裡面，某些是要登入後台，但是後來手機登打也用得到，也可以轉成API。

因此我希望兩個分別列：一個是不是本來ZK的後台，而是別的登打或機器對機器界面，那個是現有的盤整。

還有未來不管是手機登打或者是新規劃的機器對機器，那個是我們希望瞭解的。

後面這個不會要求在汛期之內處理完成。

如果你們希望優先更新哪一些子功能，真的比較需要，不是現有的介面就可以處理的，也都可以列進去，大概是這樣子。

接著是第三項，也就是「如何增強登打於EMIC之資料可用性？有瑕疵之資料可否檢核後標記或退回校正？」

分兩點說明：第一個，這個是目前EMICUI的介面，其實是有做線上的資料檢核。第二，介接進來，比如究心科技從紅十字會或者是慈濟介接進來的資料，在實務上的考量，我們希望資料先介接進來，事後再用batch的方式去檢核資料是否正確性。不過我們遲疑的是，因為我們在回覆給究心科技的時候，他有辦法再回過頭叫慈濟這些志工再將資料修正嗎？因為颱風已經過了，他們是否能夠有人力來做，因此我們覺得這個是收效比較少。

兩個想問的。第一，我們目前匯入整合之後，其實我們從外面的Open Data，我們看不出是從哪裡來的，並沒有一個來源端的標記，所以其實我們連跑到非洲、赤道，或者是各種各樣奇怪的格式，我們也沒有辦法追溯是哪一個上游介接系統給我們，對不對？

我們系統上可以看得出來。

有來源ID嗎？

對。

那為什麼來源ID不公開？

我們公開其實當初的想法是災情資料，因為災情有可能是A發現會報，B從不同地方也會報，會併案總一個災情，因為對我們在業務上來講，我希望從更多的管道知道我所有的狀況，可是我也希望最後執行的同仁不要太多的狀況，如果可以的話，就是真正確定有哪一些案件，是併案的部分會有一些處理。

當初我們在Open Data的想法是，總共有這一些災情，因此沒有針對個別不同災情的來源，我把這一些資料也公開，這個是目前沒有的，第一個部分。

第二，政委問的EMIC可用性，我們問的是災情的部分，另外一個EMIC的資料來源很多其他的部分。

首先講在災情的部分，不管是119或者是1999或者其他線進來的資料，原則上我們只有簡單的，如果在UI有相關檢核的介面，如果通過資訊系統機器對機器的測試，我們在進來的時候，就沒有再檢驗了，比如像地址或什麼，認為地址檢驗的話，會有很多資料進不來，我們也有討論這一個部分，我們不會在報進來的時候直接退。

不退件，這我們上次同意了。

我們每次應變中心結束之後就撈這一些相關的資料，對這一些資料的正確性去瞭解跟評比，會不會某一些系統，或者是特別希望資料怎麼樣的調整，我想說這個會變成日後在應變中心結束之後的作業程序，慢慢把這一些，尤其是機器對機器的資料調進來，如果有一些必要的檢核，就是請對方的程式檢核或什麼，這個動作我們會做，這個是在災情的部分。

其實我們在EMIC也有介接很多相關部會的資料，我們也發現很多場所的位置是定不到的，這個部分我們未來今年度開始，也會針對所有的資料分析，然後再把這一些資料，也就是整個資料，好比位置是錯的，有一些部分是原本的地址門牌資料沒有，所以我們會請內政部資訊中心去協助我們把門牌建完整，或者是我們告訴源頭的原始機關資料錯的，請他們協助我們做處理的動作。

這個部分我們會從業務單位的立場，去處理這一些東西，並把資料撈出來檢核。

我們認為這並不是一次、兩次應變中心檢核出來就完成，我們會持續性做處理。

抱歉，但還是沒有回答我的問題。

為什麼檢核這件事只能由你們做？為什麼不能是你們釋出開放資料集的時候，就是上面有標來源，然後以及併案過的分成兩個資料集，你們這邊有標來源的，這個是我們做資料檢核要用的？

按照你的說法，可以有同一筆災情A、B、C都報，但是並不是只剩一筆，這一筆取裡面精確度最高的欄位，這個是非常好的、是正確的，但是我們如果要找出資料可用性的pattern，我們要找A、B、C三筆，有一些在非洲沒有標好，有一些地址門牌找不到的raw data，既然raw data都是公開的，為什麼不能開放出來讓民間或者是其他的事業單位檢核，為什麼一定要在內部的資料庫做？

之前沒有做想過這一個問題，也就是沒有針對這一個問題處理。

政委的意見我們會考慮，我們是不是每一次災害的當下，也把所有的資料都提供出來，這個部分就我們在程式調整，這個部分是可以做到的，我們看一下這個部分是不是可以提供。

我看你們後端的程式有這個資料欄位了，只是沒有接口而已，其實只是開一個view，它並沒有成本。

那個data我們會多給一些，不是不能做，我們只是沒有考慮到做這樣的動作，我們可以處理。

好啊！只要法律上或政治上沒有什麼問題的話，我是建立建議這樣做。

因為資料可用性的分析，不只是各位作為當然專業的業務來作判斷，它裡面也包含了地理資訊、包含其他的專業，如果都開放出來的話，別人也可以幫忙檢核，我全部只是這個意思而已。

瞭解。

接著是EMIC壓力測試，可否以梅姬颱風之規模做兩至五倍的壓力測試？

上次報告的時候，壓力測試就是以梅姬颱風的量來作估算，不過以那個單位的時間來看的話，梅姬颱風是兩天，也就是26日至28日，是在一個小時裡面壓量，其實壓力是梅姬颱風的兩至五倍，但是我們之後的壓力測定，我們還是會做增加這個量能。

按照你說的是四十八倍，是不是？但是梅姬颱風也是有一個尖峰期。

我們沒有抓時間來比較，所以之後在壓測的時候會再作調整。

我理解，之前聽的時候就有理解。當時不知道的，是梅姬颱風是集中在幾個小時裡面量的最大值，假設梅姬颱風當時只集中在兩個小時，這樣壓在一個小時測，也不過是兩倍而已。

所以我覺得既然上次壓測有一個子系統已經出現問題了，我們還是要稍微至少再把這個加倍，知道那個子系統只是狀況會稍微差一點，我們就不用再改程式；或者會突然崩潰，那麼我們就要再改程式。

接著是「EMIC手機版可否直接往API first的方式設計，以達到手機版網頁只使用API與Server溝通，即前端頁面與後端服務為全分離之目標？」

技術上是可行的，但是還是要跟業務單位盤點，哪一些是第一層需要帶行動裝置登打的，這個部分決定之後再委外辦理。

這個不是在今年度的計畫裡面？

對，那個還沒有發包出去。

預計什麼時候？

這一、兩個月。原本已經打算公告了，有這一些議題，我們回頭再修改一下。

好，你們公告的範圍並不改變，只是把它加成需求而已？

是。

最後一項是EMIC及NCDR前端可否整合？昨天早上有跟NCDR討論，我看了他們的簡報，等一下他們會作詳細的報告。

不管架出來是什麼樣子，掛在你們網域上是沒有問題的？

對。

謝謝。我們就直接鏡頭交給NCDR。

非常謝謝消防署給我們這麼多的協助，謝謝政委就整個擴充評估及哪一些問題，我們用PPT來說明一下，請蘇博士來說明一下。

主席、各位與會先進大家午安，中心針對上次政委的指示，希望在短期內能夠達到目標並進行。

不好意思，打斷你，真的不好意思。

這個資訊量有調整，意思就是我如果上了這個圖台之後，以後就沒有那麼容易選單，才能看到八仙樂園或者是「玩水不玩命，安全放第一」或者其他的東西，這個從消防署的角度是ok的嗎？舊的專區要按比較多次或者是比較少人看？

目前NCDR在做的時候，我們看到左邊的災害情報站是平時的網頁，就是讓你選。但是理論上在災時的網頁，現在是把主視覺換掉，其實下面還是會有我們的比如條列，像這個是會有後面災害應變紀錄或者是2017年或者是2016年的資料可以處理。

我想這個還沒有成型的示意圖，未來我們會把像放在宣導的相關訊息，我們會直接另外會由輸裡面的妨害宣導網站，那個是平時的作業，災時的作業就會看到像現在目前NCDR展示的部分。

為什麼平時不能看這個？看這個有什麼壞處嗎？

沒有什麼壞處，而是因為災害來的停水、停電的資料，平時不會有的。

確實。但因為NCDR也有預警性質的功能，如果平時不show這個介面，而災時的時候才出現，其實民眾不會那麼容易去瞭解。

除非你的論點是平時沒有任何有意義的資訊給民眾看。

其實也不會，可能是我們疏漏了，我們跟NCDR可以再討論。

所以有一些，其實我們也有彙整一些，像這樣子的資料，好比豪雨特報，因為並不是特別災害的資料，我們也會有的。原則上，如果是這樣的話，我們可以朝向把防災宣導的資料拉掉，因為本來消防署就會有宣導的網站做這部分的處理，災害應變中心的災害情報站就是這個。

對。好比空氣品質監測，其實我們要說災情的話，一年可能上百天（笑）。

我的意思是，既然有這一種平時監測功能的話，我認為不妨平時也把它放在這邊。

其實災害情報站平時、災時都有作用，所以才會看到平時的畫面，而未來是會如右側上面圖太的部分，昨天跟NCDR說，原則上NCDR會提供圖台，我也會去看。

災時有一些特別的，像應變中心跟相關的新聞稿，像會分在另外的區，我們就投一個上去。

我補充一下，這個是很可能設計上的不一樣，因為是災情的預警，所以我們儘量不給民眾增加loding，因為看到字就轉台了，所以看到災害青網就是以圖為主，要看供、供電或者是道路中斷，就以上面的頁嵌就看得出來了，我們設計的方式是儘量用一個圖、一個表及一個說明為主，我們是用簡單的方式為主。

像PM2.5就是不發生災害，對我也有用的東西。

你要看PM2.5的話，一按就瞭解了，但是很多人不想受到污染，看輕鬆愉快的東西，也可以（笑）。

可以同意「不要首頁一打開就出現PM2.5」，至少在解決這一個問題以前（笑）。

這個設計上我們可以討論。

整個資料面的部分，目前是從國土會側中心或者是TGOS提供WMTS的標準底圖給我們，其實裡面有衛星跟電子地圖的部分。

其實我們就有考量到一點，未來提供給更多人服務的時候，loading勢必會增加，所以請內政部未來在提供服務的時候，可以顧到這一部分的loading，這個會牽涉到未來穩定性的部分。

對於整個圖資的部分，有介接到圖資，像氣象、水文、坡地及道路，像平常也可以看到淹水災害、坡地災害、液化資料等等，可以到這邊來查詢。

大家比較關心的是民生的資訊，像現在努力介接的是水電民生的部分，今天早上有跟水電公司談過，水的部分比較沒有困難性；電的部分，行政區還是侷限在鄉鎮的範圍，所以這一塊後續還要再突破的地方，也就是介接的資料怎麼樣呈現。

不過我們上次有說，真的只能給到鄉鎮等級，我們就標鄉鎮中心點比較模糊的區域。

對。

好比跨兩個鄉鎮，不知道哪一個，就兩個都顯示？

對。

我們希望未來可以服務更多人，所以我們希望可以合併於政府雲端設備裡面，初期規劃有幾個伺服器的需求，一個是AP伺服器，平時規劃五台服務，災時的時候我們希望可以做到自動擴充，因為災時的量能沒有辦法估，有時多、有時少；資料庫的部分，我們目前是用SQL的部分，我們希望可以擴充，也就是HA的部分，我們這邊也希望檔案伺服器及介接的伺服器，初估的金額是1,500萬元。

整個人力的部分，我們會分成兩個階段來看。接著是短期的部分，中、期沒有在規劃裡面。

我們放五個人力作硬體調校的部分，未來雲端的調校，像程式架構的改寫及資料介接的部分，未來我們穩定以後，我們希望一個營運的人力，這個部分我初估有四個全職的人力，包含了設備的監控，我們希望一個緊急製圖的部分，因為有一些圖資並不是平常介接就可以了；像高雄氣爆是臨時性的，我們會有緊急圖資上架。

整個的時程規劃是以四個工作月來完成，包含了環境兼之、資料介接、程式改寫，初步的預算大約是在600萬。

程式改寫具體來講，我記得你們用ArcGIS，如果要用所謂的雲端圖台，你們還是用ArcGIS嗎？

對，初期我們還是建議先用ArcGIS。

就不會先用SuperGIS或QGIS或GRASS這一類的東西？

對。

簡單來講，你們並不是真的去用內政部的那一套GIS。還是用你們的ArcGIS，只是圖塊由SuperGIS出？

對。

也就是說，不改你們的軟體架構，只是在硬體上多一些可用性？

對，軟體資料不改，但是資料介接的方式可能要再改。

這樣ArcGIS Server要放在哪裡？

未來可能要在雲端裡面放硬體，但是比較不會有擴充性的問題。因為現在雲端，我們就買license買幾台，要再ArcGIS原廠公司談，如果原廠的部分若要擴充的話，後續還要再談，像目前消防署我知道有發license。

你覺得純粹以GIS Server的loading瓶頸，不會在ArcGIS這一套東西上？

我們希望儘量減低ArcGIS圖台的服務，儘量以檔案的方式，像用JSON的方式來提供服務，這樣子loading會降低比較多。

就是幾乎接近純靜態網站的寫法？

對。

很好。那AP伺服器要做什麼？如果地址轉座標是內政部做，如果呈現的GeoJSON都是靜態圖檔，你們AP伺服器剩什麼事做？

我們過去規劃是要轉譯JSON的部分，地址轉座標，也有部分是接回來我們自己做，原則上是管理後面資料串流的部分。

所以不一定也要自動擴充？

對，現在的災情資，因為現在的介接方式不一樣，從資料庫拉回來，再轉譯出去，所以AP現在是比較大的份量，如果改成靜態的話，就不會改那麼大的份量。

如果攤平的話，平時一台就可以了

也許是。

這邊是設備跟license的錢，1,500萬，然後這邊是開發的錢？

對。

請繼續。

因應政委及葉副執秘的指示，我們希望在短期內有更快速的成果出來，我們再提出災害示警格式開發的部分，這邊是有一個災害示警存在，希望未來推廣到產業作應用。

目前整個平台裡面有四百五十二個會員申請，包含了四十八個企業單位來介接，包含Google，我們也透過這一個去服務，每一年千萬人次的服務，我們希望未來把災害示警平台再擴充其服務對象。

可能會面對到一些問題，像目前是放在我們伺服器有四台營運，如果要擴大營運的話，四台是要擴充。

再者是，我們也希望推廣地方去做示警的標準，像在台北市，我們目前看到水門關閉的介接服務，也是用CAP去作發布，我們希望擴展到縣市去作相關的示警資料去發布服務，不管是手機或者是其他的裝置都可以介接。

像美國是在電視機裡面已經嵌入到裡面，電視機就可以警示的資訊，所以未來我們希望能夠朝產業化來作發展。

這個CAP XML檔是你們收到之後就產生？

對。

是從你們gate這邊pull？

對。

無論如何都是靜態的，並不會給這四十八個都一樣？

對。

如果現在只針對四千八個個介接，你的CPU用量應該是相同的才對。

應該也會有部分的影響，通常還是會有一些運算，再提供。

但傳送幾乎沒有運算可言，push是HTTP出去，你只是做一大堆POST的要求，但是既然你的要求都一樣，這一個東西其實應該不需要動到運算才對。

這其實就是一堆sendfile(2)。

你們現在有benchmark過說你們CPU loading現在就已經很重嗎？如果是的話，那就是程式沒有寫好；這應該在沒有額外CPU的情況下就能做。

如果真的需要更多運算量，我們這邊也可以撥，但我還是想要知道你們架構是什麼狀況，因為送靜態檔案其實有很多方法做。

請繼續。

因此除了硬體擴充以外，包含整個後續的資料加值，像政委有提到台水的資料是不是也可以作CAP應用，後續的開發人力跟設備，目前初步的經費是2,000萬，以上報告。

這2,000萬是另外一回事？

對。

平時、災時是兩回事？

對。

這個是加值的營業單位，幫其他還沒有做CAP的這些朋友們去做結構化。

所以這2,000萬元的意思是我們幫這一些單位付了錢，就可以免費用你們的服務，意思是這樣嗎？

應該是說，一方面如政委講的，一方面我們也是希望除了從幫助政府單位，也希望可以服務產業界的部分，去拓展更多的使用者。

我們幫產業界付了錢，所以產業界可以用？

對。

好的。不管剛才這個或者是對於新的東西，不知道有沒有什麼想法？請自由發言（笑）。

政委不好意思，內政部資訊中心，剛剛NCDR講示警的部分，為什麼不用Open Data做？

目前已經是Open Data。

既然是Open Data，不應該會有這個問題。

他說有主動推送。

可是推送的話，按照那一個機制，其實只是頻寬下載量的問題。

是的。你們目前頻寬的用量？

而且這個用量是要集中在data.gov裡面去做或者是在……

……你們現在推送是用國網的CPU或者是？

現在是在我們中心裡面，我們中心自己的。

他們想要把接到推送的頻率跟端點建置到你們的資料庫裡面，也就是每分鐘或者每小時看到碰到頻率就推送出去？

對。

如果這樣的話，就像剛剛說的，其實都一樣的。你們每一分鐘都會推送出去嗎？

其實看對方有沒有發示警的資料，像氣象局有發，我們就會自動推送出去。

推送都是走HTTP，並不會走簡訊或者是CBS或者什麼別的？

沒有，全部是HTTP跟FTP。

這樣真的應該沒有運算量。瞭解，謝謝。

不曉得還有沒有什麼想問的？

我是科技辦葉副，提到這一個部分，都是比較像短期的面向，這個是非常clear，還是我上次在會議中所講的，中期的面向？

我一直比較care中期的面向，不曉得大家對於中期的面向什麼想法？

上次中期的面向，我們有一個具體的詢問，就是剛剛這邊具體提到說需要HA，然後需要一些可能發生災時自動擴充。

雖然擴充的情況不一定那麼多，但是我們假設這個是災害時，最多到十台，就是說有沒有可能放在內政部這邊的集中建置機房裡面，或者是簽個HGR，或者是跟Google彰濱機房簽一下？

我想跟長官及部裡面說明，這邊正在做資訊機房的集中，我們也跟消防署談過了，因為消防署現在有很大的問題。

而且已經不夠用了（笑）。

我們後來說好，把它納進來，到整體的雲端服務平台一起來推動，這樣資源才可以共享。

因為要的就是災情時間，要很大的資源，但是如果以他自己來做，其他的時間都會比較閑置，這樣很可惜，放到部裡面會有規模，如果這樣集中起來，根據我初步估算，大概會將近兩百台，所以絕對足夠支援消防署在災情的時候，因為災情的時候大家都放假的，災情發生的時候，反而可以提供比較大的能量。

因為颱風時不會有人來查地籍資料（笑）。

比較沒有那麼大的使用量，資源可以共享，比較不會浪費。

我們分兩個計畫，一個是內政加center，目前會碰到國發會公教的計畫裡面。另外一個是我們會建置一個內政雲端服務平台，到時候也會把消防的業務併進來。

後來同仁跟我講說NCDR也有意思要來加盟（笑），若這樣的業務量，其實如果能夠join進來也是好事，如果這兩個計畫有奉准，這樣就一起來推動。

剛剛有談過，如果是平時的話，NCDR應該不會超過五台的用量，事實上五台都用不滿，其實跟消防署一樣的狀況，但是災時的時候就會漲一下。

我的意思是這邊長的程度跟那邊長的程度是一樣的，因此當時葉副才建議是不是乾脆用相同的HA架構，畢竟不希望整合成網頁之後，使用者看上半部是好的、下半部是壞掉的，或者是下半部是好的、上半部是好的，好像哪裡怪怪的（笑）。

我補充一下，現在很多人都用TGOS，TGOS原來是放在中華，未來會把TGOS弄到內政部的雲端，其實這三個如果擺在一起，在整合的運用等等，其實穩定度可能會比較好一點，不然還有很多各自的介接或者是通訊都斷了，其實若放在一起，以後我們也會做到異地備援，我跟同仁講說未來異地備援，平常異地備援，如果災情的話，兩個入口都會處理，兩個都balance，其實有些時候一個出入口是很危險的，資料要多一個節點進來，才可以達到分散跟分流的目的，異地備援做到幾十倍，所以兩邊的data是一樣的。

NCDR是目前完全沒有任何類似的架構，就是Active-Active、Round-Robin Load balancing？

其實有，我們自己有在設計。

這幾台裡面有做？

有在試小規模的，沒有辦法一下就擴展到那麼多。

我以為你們放在同一個地方，所以其實不是，如果壞掉的話，是有？

對。

是哪兩個地點？

在中心有、國網中心也有。

如果壞掉的話，國網會自動接DNS？

對。

但是如果平時是DNS是會隨時解到近的那一個嗎？

我們會用網址去判斷，就是我們現在有EOC dss跟EOC dss1，在國王那邊EOC dss1有作過平衡，但是左右各跳。

所以事實上你們沒有在DNS層，去說若離國網近一點就用國網的？離你們近就用你們的？

對，現在沒有。

但是未來本來有這一個計畫嗎？

原本雲放在Azure上，去年測的結果是距離太遠，我們在台灣沒有機房。

對啊！所以我剛剛說彰濱機房，要try就是要try Google。

但如果內政部資訊中心這邊已經有幫忙規劃這個的話，其實也許用這邊的比較快，不然這一整套，維護本身就有非常多的人力，如果三個系統用full time去維護，其實到最後結果是一樣的，真的不如集中在一個地方維護，所以如果願意的話，那真的非常感謝你們。

還要政委幫忙，目前計畫還在過程中，到時候還要push一下，不僅是消防或者是防災，其實對於整個內政來講，其實很多的戶役政，都是相關重要的，請政委多多講話，這樣資源的統合跟人力的應用。

像內政單位跟人力整合起來才能做這一件事，像移民署就有一、兩百個人，但是我們消防署在幾個人，就是這樣，差異太大，如果整個災期，人力資源就可以幫忙。

以上有沒有回應到中程的問題？

我還有一些（笑）。

我再請教一下問題，中期來講CIID到底要到什麼程度？Critical infrastructure information的部分，我們到底要做到什麼程度？

每個節點會自動匯流嗎？到底要怎麼樣？現在有各式各樣填表的，到時候自動解析嗎？我不曉得，可能我專業不夠。

這邊講的是關鍵基礎設施，目前在災情發生時各自的可用情況，是用什麼方式。

國土辦現在正在建置。

也就是「我們現在沒有答案」的意思（笑）。

他們需要幫忙，我們當然是幫忙，這個沒有問題。不過剛剛所講到機房建置是明年，我們每天在打仗，災情的預警不是開玩笑的，午後局部大雷雨，就忙得昏頭轉向，為什麼我們會自己開發做這一些事，因為要應付所有長官資訊的需求，所以目前大概是如此；當然要回歸到哪一個地方，這個都沒有問題，國土辦部分，我們再幫他忙。

到時候是要介接國土辦的資訊嗎？因為國土辦並沒有像這一個團隊這麼有……（笑）

……國土辦與災防辦太熟了......

周老師要講什麼話嗎（笑）？

國土辦那邊就我瞭解，應該沒有系統，只是針對查核。

這個我瞭解啦（笑）！所以一開始老闆們的意思是，把這一個系統導進去，問題就解決了。

我們有幫忙規劃。

也就是說，還在文書作業的階段（笑）。

皇帝不急，急死太監，畢竟我們是行政法人，我們送了很多資料給他說要做什麼，他們當然也很努力（笑）。

不過就是一步步來，我也只能這麼回答。

沒有辦法，因為很多資料的建置，基礎關鍵措施，為什麼會有各部會這麼多的資料？

我想很清楚，公文來、公文過去，到現在都沒有辦法完成，都是私底下拜託跟把資料建置好，我只能這麼講。

這跟我理解的相符合。我本來是說我們是起一個示範作用，開放的過程大家都有看到逐字稿這一些東西。

我希望盡可能做到不挑實際的機房，不管是在東七或者是國網或者是HGR，或者是哪一天去彰濱機房，沒有特別挑放在哪裡。

如果系統建置成這樣子的話，未來也許整廠輸出……這可以叫「輸出」嗎？

或者是轉移或者是copy給國土辦的其他朋友利用都有可能，這個是技術上的規劃，這個就不是我的專業了（笑）。

所以不知道還有沒有什麼？

我的問題比較多一點（笑）。

水電維生是？是大電、小電？

上次政委協調的部分是台電跟台水，我想以這個為主。

還有道路本來就有。

但是道路就是上次看到公路總局出來就是都文字的部分，我們希望再細膩一點。

知道，這個就是加值服務。

「氣」呢？

「氣」是經濟部能源局管的。

這一塊比較少。

上次高雄就發生了，上次高雄氣爆我們就整合成功了，縱使自己本部還沒有整合，我們都已經整合成功了，本部還不曉得，我們全部把它弄好，這個也是屬於基礎關鍵措施之一，瓦斯即「氣」……反正就是一步步（笑）。

不是啦！我現在在想說，你們把它放在擴大公共建設裡面已經是一個案子，所以哪一些項目到時候會在裡面看得到？

是四年以後嗎？

對，大家都在閃這一個問題，所以我只好請大家把問題的填寫單填清楚（笑）。

「氣」不是碰到每一個地方政府圖資解決方式不一樣的問題嗎？當時我在g0v的時候——嗯，我現在還在——社群處理氣爆最大的問題是，管線還需要透過認識的朋友提供出來，根本並不是Open Data。這個解決了嗎？

我們非常謝謝你們幫忙。

謝謝，我們也常常是靠臥底的公務員幫忙（笑）。

是啊（笑）！也是這樣來的。

這段沒有逐字稿吧！

當然有逐字稿（笑）。這有什麼問題（笑）？

這個也許就是point，有一些是地方政府，有一些是中央政府，我們也是拜託、拜託，才知道怎麼會拿到這個。

說實在講不清楚，像台北市自己認為，有建議排水道或者什麼台北市的瓦斯，其實是屬於地方政府的建置，這個就是地方政府的層級。

如果以四年為期，哪一些地方政府跟你們配合很好，我們進數位國家的架構，理論上六都在裡面，六都要管非都縣市，可以說這邊有了、那邊為什麼沒有，就是用慢慢這樣的方式，來讓標準齊一；但是我們看各國的經驗，沒有一、兩年，是連欄位名稱做不出來。

但是我們有四年。

如果葉副很希望的話，我們可以納入（笑）。

只是說我們四年之後，這塊拼圖不一定在每一個管線或者是layer都拼起來，到最後可能是六都裡面還有三都，以及旁邊的非都縣市有給我們高解析度的資料，其他只是文字說明，四年之後也只能到這樣。

但這樣也不算失敗，因為我們只能顯示我們有的東西。

國發會資管處莊盈志，這個議題往前看目前可以做的部分，我剛剛看了NCDR，在網站上提供一百多示警的相關資料讓民眾提供、申請及下載使用，這部分的資料有沒有辦法進一步放在政府資料開放平台，讓更多人免申請就可以申請相關的資料？因為目前有十六項的資料集，目前在NCDR上，我看到有一百多項的資料，中間還是有一點落差，是不是想說就還沒有提供的部分，可以進一步去做研議，看是不是可以讓民眾都能夠用得到。

這一個我們上次開會時有討論過對他們來講比較關鍵的，目前他們很多的節點，還沒有想要大張旗鼓宣傳，放到「Join」，是因為包含圖台跟計算會吃不消，如果是固定時間，好比是每一個小時，只要不要設到太短，其實運算量是固定的，我們也可以用CDN或者是其他分流方法用到靜態檔案來提供，因此才會有今天的規劃案。

應該是說我們把靜態檔案為主的成構出來，每產生一筆就要算一次，又要回去算一次，我不知道為什麼本來寫成這樣，但是想必開發時比較容易；程式工作花四個月做完之後，比較能夠達到盈志要的東西，任何人都可以來介接、隨時都可以來介接，這是幫NCDR說一下話（笑）。

技術上的東西我們不是很清楚，再作建議，我想有兩個部分：

這個也涉及到另外一個問題，像交通部一些單位，是不是可以把資訊放上來？不然人家會說，有些媒體的長官來看為什麼這一個入口並沒有這一次災害的相關資訊，好比像空難，這個是大家會誤解怎麼回事，不然行政協調也是ok的，而外界會誤解，這個是不是有窗口把資料送上來，或者是內政部提供這樣的服務？

目前已經跟經濟部接了。

並不會單獨拆開，而是發生重大風災或者是地震的時候會放上來，像空難的死亡人數及處理狀況，有一些人在這邊看不到，可能會到交通部民航局去看，到底是不是僅限於風災跟地震，會有這樣的問題。

另外一個，NCDR的產品非常多元，剛才提到災害情報站之外，你們有一個watch系統，應該是屬於比較前端情資模擬，或者model 分析。如果這一個案子要做的話，是不是在watch系統嘗試要上架？

NCDR要回應一下嗎？

我先回答周主任後面所說的部分，像國發會長官提的政府data，其實我們介接政府這麼單位的raw data，其實都有放在這個地方，比較不一樣的是，我們把它加值出來，然後展示出來看起來比較酷、炫。

有一些是預測的東西，在災情裡面，不管是中央或者是地方政府，說實在我們也走遍了全台灣的縣市，有一些縣市首長會非常concern系統對不對，像watch的系統有人會批評，是不是把政府的raw data已經加值，要看很簡單，平常都可以看得到，也許可以看到藍色的點（簡報第2頁右側圖的右側藍色桿狀圖）也是我們加值水利署的資料，可以看到那一根監測器是20公尺。

像剛剛周主任有提到一些寒害的所產生的結果，raw data絕對沒有問題；加值的部分，有一些民眾還不太適合。

民眾不適合的部分，並沒有強求，你們本來就有縣市專區？

如果提高的話，也許就會好一點。上個禮拜周主任跟我們一起到台南是，我們被市長從頭抱怨到底，說什麼不準，而是抱怨我，而是抱怨很多政府單位，把很多口水吐在我們身上，我們回來也要跟政府單位說要準一點，像raw data這個部分問題大了，因此這一些預警的部分，我們作展示面為重。

只要你們加值過，然後套某些模型的資料，你們以Open Data的方式放給不同人取用，因為準確率的關係，不想惹不必要公關上的麻煩，所以暫時還不宜提供；但是有縣市政府有反應的時候，不但會提供，而且會按照要求客製化，讓它更準，也許四年後（笑）。

不僅我們在提供，像科技部現在也有跟各地方政府的學校單位合作，比如台南是介接的是成功大學，而成功大學會在旁邊盯著他看，成功大學也許會講說有一點問題，會提醒縣市首長說這個準確度不是很高，因為是在地，所以很清楚某一個地方的變化，好比運河去年淹水，漲潮的時候，因為氣象局的潮位觀測站不是很準，所以說漲潮可能會提早或怎麼樣，我們在台北會覺得可能沒有那麼早漲潮，那就差很多了。

差幾分鐘就差很多了。

我還是要問說，這裡面品質的可用性，你覺得四年的調校之後也許就比較有信心了，可以變成常設性的服務？

可以啊！其實今年的挑戰，應該可以（笑）。

葉副，那你的範圍又增加了（笑）。

第二個，關於輻射或者是其他的災害？也就是任何災害防救法裡面，生物病源、毒性、空難、海難……

就是現在可以管理到的（笑）。

任何的災害是由各目的事業主管機關、各部會提報到行政院災防會報，登錄之後我們會納進來，這沒有問題，像剛剛提到的核子的，有的，核災進來了。現在環保署也準備PM2.5，也要提報到災防會報，只要一經過政府最後的決議，都沒有問題。

只要災防會報簽字，你們就接？

對。

我想應該兩個部分，剛剛周主任的部分是說災害情報站，當然圖資的部分，NCDR的部分是說只要有那樣的資料，圖資的部分接是沒有問題。但是很多災害，比如像上次的交通事故或者是空難，並不會有GNS的相關資料，可能會圖片、資料及新聞稿，今年我們災害情報剛好會做一些調整，我們會就一些既有的框架，我在目前的災害應變中心會有新聞稿或者是相關狀況的錄出，我們看要用什麼方式，如果有這部分的資料，好比有這一次蝶戀花的事故等作用，這個部分都是word檔，這個部分我們就做後端的上稿沒有問題。

長期來講，各個部會在各個不同的災害，也就是主管部會不同的災害，他們有哪一些災害對於哪一些資料錄出的部分，我們配合災防辦來蒐集。

因為現在目前裝現在的框架，未來是RWD，會有一個個模組，未來可以提供交通部可以規劃交通方面的資料，看什麼東西來處理，我們也希望兩、三年到四年的期間可以這樣，如果部會有提這個資料就可以上，如果像有一些部會，我們看起來也大概是用模組化這一個東西，我就直接拉這一個框進來，其實針對這一個災害的部分，我就會有這樣的資料；技術方面我們再想辦法處理，業務方面也麻煩跟部會作一些協調。

其實你們本來介接的格式，跟CAP比起來，我覺得有一個比較大的問題，你們沒有一個我們平常設計上會叫Trivial、Miscellaneous，你們這邊沒有規劃的欄位，但是他們有的，你們沒有用一個額外的欄位JSON，他們放不下的還是放下來， 現在變成進你們再出去的時候，資訊就只會變少，也就是資訊減值的平台，所以在規劃的時候，也可以想辦法考慮進去，有沒有辦法把比較類似的附註，但是不顯示，還是存在的部分。

我們目前的規劃都是給我們自己用，所以要什麼就放什麼，不要的就沒有，那個是目前的規劃。

可能一個部分是葉副有提，我們四年的中、長期規劃，我們是不是盤點我們相關的資料，有一些不管是剛剛政委所講的，有一些就是用API介接的方式。

我們之前可能只考慮到我們自己用，未來考慮到這一個資料層面有多少，公開的部分，只要沒有任何個資等問題就全部open，變成我也是使用者之一，並不是自己做給自己，我也是使用者之一，我用的時候就是挑我用的部分，我給的部分就是給全部。

至少登打跟介接進你們這邊處理，他們有別的額外來源，像氣象局，他們本來是什麼欄位就是什麼欄位，但是就像剛剛提到其他機器、機器對接的，盡可能進什麼，只要沒有機密的問題，公開資料就出一個raw的版本，別人接或者是清洗就不用做，第二個是做資料正確性檢查的時候，本來已經有額外的欄位，只要fit你們的欄位，非砍掉一些不可，我們也盡可能進去之後原樣出來。

CDX就是一個想法，只是我們沒有災情的CDX而已，所以我們現在在建置的時候把這一個想法想進去，並不是要馬上改成這樣。

我們會配合。

不好意思，謝謝你們（笑）。

我還有兩個問題。第一個，歷史資料呢？

是颱風跟地震？

歷史資料非常重要，因為作風水的，常常發生問題，一定是風水不好的地方，是不是這樣？那一定是要有歷史資料。

颱風跟地震的資料沒有問題。

用同一個圖資，甚至社會學家要做歷史資料或者是財富分配或者是財富移動要看是否有關係，這一些需要歷史資料，那歷史資料呢？

颱風跟地震沒有問題，我可以回溯，但是像周主任提到的交通跟火燒車，這個我們沒有辦法，因為我們只負責天然災害。

下一階段是不是可以把歷史資料建立起來？

你的定義？

我要定義什麼？

就是颱風跟地震，因為我們負責這一個部分，五、六十年前沒有問題，我們全部可以抓出來。

好比去年尼伯特颱風當時的雨量資料或者是當時的災情資料，這兩個是不同的概念，如果過去那一些屬於監測資料的話，那一些資料量會放在氣象局或者是水利署，如果是災情資料的話……

……如果是登打的話，應該是不刪除的。

我的意思是，歷史資料分成很多種：有的是一次性的，像車禍、飛機事件及地震等等都是一次性的；有一些是連續性的。中央氣象局氣象科就會把地震的科會把地震的強度的點標成一個，大家就會很清楚，宜蘭外海是頻率最高的，所以不管是教學或者是study就很簡單。

因為災害的形式真的是五花八門，這一些歷史資料是不是我們在系統裡面會把它建置起來，因此以後做研究跟分析的人是非常方便的，這個非常重要。

剛剛講第一報、第二報是叫做應變處置報告，那個並沒有任何縣市會一直留著，即使是蓮花颱風等等，我們現在要調一定調得到？

之前沒有公開。

但是我看你們資料庫裡面是有的，我看程式碼是有的。所以有存，不公開是什麼原因？

我們之前做Open Data的時候，並不是focus什麼資料都要公開，像NCDR會希望達到災情（情況），大家會想要知道哪裡發生什麼事，所以我們開出去的lay out是根據這個，我們並不是根據所有的資料都要公開，我們是根據需求，因此之前在通報表的部分沒有處理。只是我們內部的data base是有這樣的資料。

要調是調得到，當時不同登打系統進來的資料，我記得他們是不刪除的，也就是裡面都有。

現在是只是有人要拿這個加值的話，我們就要公開，意思是這樣嗎？

我覺得這個對未來國家的國土安排或者是社會等等規劃是非常重要的，我們一直在討論這樣的問題。

其實我們可以考慮後續的規劃，因為這個部分理論上有時序性，通通都放Open Data平台，看起來也是……或者是要做什麼研究可以申請，有哪一些資料集，你需要的時候就申請。

但當年看的時候是不用申請，怎麼現在反而要申請？

並不是這樣，而是有一些在Open Data上，該給的就給；如果整個想要知道歷史資料，其實timestamp一都定要有，像剛剛葉副講的研究，包括比如哪一個颱風什麼時候的風速、雨量在哪裡，有沒有什麼災情，可能要串很多個資料集去瞭解這一個資料，所以我們之前的想法是在我們當初雲端計畫裡面有一個資料服務平台，都能夠有這一個資料，是不是我們自己要對外公開，那時候還沒有很完整考量，未來是不是要做這樣的公開，我覺得我們可以在這一個計畫裡面，我們可以參考是不是達到這樣的目的。

參考實價登錄的那一套系統，他們協調過無限多次之後，除了當期的放在Open Data，之前可以按月、按季，如果按照你們這邊的講法，每一次災害close之後，每一次都放在zip檔，放在目錄裡面，就可以下載。實價登錄是用月或季來算，並不是用災害來算，但是概念是一樣的，同時放一個有壓縮的存檔，這個是作業的一部分，並不需要回溯再整理東西，平常每一次關檔的時候，就把它壓縮起來，這個是一個可能性。

但是，如果你們現在是把raw data都做成Open Data，關檔壓縮的時候壓縮這一件事不一定是你們做，也可以ECDR或者是任何做，之前要你們做是因為沒有完全把後端的東西讓前端看到；如果後端的東西，前端都可以看得到，其實這一個留檔的動作，國發會也有一些處理的經驗，就是可以由外部單位來做類似的事情。所以，其實我們還是要把資料的保證度跟可用性這一個部分先解決，我覺得歷史的問題就可以自動解決。

這一個部分我們可以在這一個計畫裡面放進去。

謝謝。

比如我們看到尼伯特颱風，當初的所有歷史資料，包括我們整理了國外的資料，各個國家不同的資料，我們最主要是展示，如果要追訴過去幾十年前都沒有問題，每一個颱風都看得到像葉副講到要看過去的資料呈現，上次氣象局講得很清楚，是北部的擦邊球到下邊球，這一些東西都可以很清楚看到它的變化，歷史資料都不會刪掉的。（提供災害情資網的颱風動態頁面）

這資料量不大。

但是有些人希望災情等等……

這裡面的災情，還有裡面你可以進去一直看，我們上次有展過了。

上次經濟學家跟我講說，如果有這個東西，可以瞭解財富因為這一個颱風過去變遷、人口行為……..

......喔！《21世紀資本論》那種研究方案（笑）。

我覺得國土跟國家的安排是非常重要的，因此我們希望在中期計畫裡面，這一個東西是可以作一個數據的資料，其實對未來的研究有關於國土規劃。

也沒有花多少錢。

最後一個問題？

中期規劃，誰到底是負責的單位？

每一次唐政委開會的時候，唐政委就一肩扛起，這樣不行。

而且從現在算起四年，我應該不在同一個位置了（笑）。

所以這樣不行啦！你們都害唐政委，這完全都沒有道理，本來根據部會的分工，跨部會的計畫就是要一個單位肩膀扛起來當主責，不能唐政委主責，這個完全沒有道理，我看不下去了（笑）。

我只是幫忙系統分析而已（笑）。所以現在既然要放EMIC首頁，是不是？

我才知道我要去追誰。

所以我們現在是要猜拳嗎（笑）？

我補充一下，有關於今天講的這些計畫，其實像昨天我們在審5EG的107年先期計畫時，國發會在找外部的一些委員一起進來審，他們對於消防署提報的救災雲，就是把整個災防整併在一起，未來在5EG計畫裡面，因為5EG計畫是四年期的計畫，我們持續希望在內政部整體修改的狀況，就是符合委員的需求，因為委員也是覺得不要救災是一個，不管是雲端的服務或者是5EG服務，也就是計畫調整的狀況，畢竟這現在還在審查當中，其實施主任也知道委員一些意見，他們也會去作調整。

另外一個部分是有關於雲端機房的部分，誠如剛剛施主任所提的，因為我們在未來「DIGI⁺」裡面確實是有建立公教體系的綠能機房，內政部也提報這一些計畫了，我們近期蒐集好這一些計畫之後，我們也會趕快審查完畢、儘速落實。

所以意思是，不需要我大力幫忙就會有（笑）。

必要的時候，還是會請政委出來幫忙，希望打通人督二脈的時候，就會請政委出來幫忙（笑）。

理解。

還是沒有回答葉副的問題，這整套然體系統可以活在任何地方，機房的問題解決只不過解決了未來擴充的問題，只不過說機房連軟體PM都要做，這個也可以（笑）？請資訊中心擔任大PM的角色。

我們可以做中介協調角色，但是執行面是他們兩造。

好，你們協調沒有問題。

大PM是誰？

我們負責協調。

負責協調的是大PM。

但是實際執行是他們，因為中心本身並不是這一個主責，因為我們對整個的know-how，還是有一定......

……不過現在他們現在要你們的圖資了，就是底圖跟planning。

跟政委報告，如果圖資設立起來之後，假設我們把標準放進來，其實我們有一個標準的組上機，我們會要求未來符合這樣的標準，如果未來要推到其他部會進來，其實就要follow這樣的標準，不然弄不進來，這個標準我們會訂。

但是相對的，剛剛講四年計畫要去執行的時候，一定是他們來做，包括寫計畫等等，而不是資訊中心，因為我們不會去主動幫他寫這個計畫。

那當然。

這樣不行，我們還是要找出寫計畫的人。

對。

你們只是追進度的人？

可以幫忙協調追進度，但是那個計畫的內涵是他們才知道真正的需求是什麼，因此我比較建議是不是副座在這裡，副座要不要接？

業務這部分是沒問題，在人力、技術這一塊，因為這個滿專業的東西。我目前的話，事實上在這方面我們做得跟辛苦。

我會盡力幫你，沒問題，但是不是計畫主責由你們來負責協調，因為用最多的是你們，而且消防署一到，有災情，都跑不掉。

是啊！而且這一個系統的網址還是emic.gov.tw，大家看到還是覺得是你們（管轄）。

我想有兩個部分：第一，心態上要調整，並不是什麼都是你們的業務同仁做，我知道業務同仁本來loading就很大，但是好比像平時一些資料可用性的分析或者是介接，只要你們把後端的東西比較接近CDX環保署的做法，盡可能放出來，其實我們這邊就可以幫忙協調，也就是協調如何接資料或者怎麼樣存資料，或者是CDN怎麼建置，比較屬於資訊專業的東西，其實資訊中心就可以幫忙了。

第二，NCDR這邊，我們發現中期的計畫，也就是第二個部分會變成首頁的部分，我們會先把某些部分放進來，也許從你們的角度來看，也可以跟他們要一些更多的或者是更客製化的顯示方法，就像目前縣市首長對他們做的事情一樣（笑）。

因此，在這樣的權力關係裡面，並不是NCDR回來跟你們要東西，因為你們已經把手上的資料全部攤出來了，並不會更多了，所以這樣感覺上還是你們主責比較對一點，因為是你們提出要求。

謝謝政委給我們機會，救災是我們的職責，未來我們會朝這個部分努力。

短期之內不會要求你們做超過現在廠商能夠負荷的事情，大部分的開發就是這邊的朋友及三樓的朋友會幫忙。

但是從中期，就是如果確定要做數位建設出來之後，這邊寫的里程碑最後還是由消防署這邊來幫忙，這樣可以嗎？

那我們就作成會議紀錄了（笑）。

後續規劃的期程大概是四年？經費的估算？

我們已經暫時放在擴大公共建設的部分。

是4億嗎？

對，預框，但是真正多少我也搞不清楚，就是依照我的邏輯下一個數字，多少再調整，沒有關係。

我請教一下，我們副座的意思，原則上葉副希望我們擔任主責部會，按照剛剛的協議我們會做這一件事。

只是我們也要知道一些後續的期程，因為我可能會跟NCDR瞭解，我們昨天大概有談到，有一些東西比如像除了網站的部分，我們也講到EMIC的部分，有一些部分NCDR會處理及負責，我們在費用裡面就會編某一塊是NCDR要處理的。

這整個計畫，從會報這邊的要求，我們什麼時候該提什麼樣的資料？我們儘量做什麼準備？

這個還有時間。

就是建構民生公共物聯網計畫裡面有預框了。

剛剛葉副說只是概估，如果國發會審查我們的計畫，我們不能說是葉副估的，我會列出要做這個多少錢。

計畫放在前瞻基礎建設項下（擴大公共建設）。

就是某個單位審查。

你說像送到立法院？

現在是前瞻基礎建設（擴大公共建設）的數位建設，有計畫表格、計畫書，現在大致上都有，但是詳細的細部計畫審查方式，那個還沒有確定，所以現有的資料會再提供給消防署跟NCDR。

這個部分分兩個部分，一個是放在擴大公共建設的部分，那個是要送立法院，希望3月底送出去，那個就很趕。

如果是擺在科技計畫那一塊，那就會比較是每一年去滾動調整。

那個我們放在擴大公共建設。

那很趕。

但是這個是數位建設裡面的一個項目的一個子項再一個點。

您的意思是要框進去，但是細部計畫還是要寫？

還是要寫。

一百四十個字之內。

院長說3月底要送立法院。

經費的上限是不是可以請消防署再評估一下？

我們可以再調，其他的規劃都已經規劃完了，政委也都看完了，只有這一個比較復雜一點，其他的計畫，我們都請政委做最後的評估了，只有這一個是最慢的一個。

所以葉哲良沒有問題，你們直接對對。

沒有問題。

錢還沒有下來的情況下，我們能做到什麼程度？

我已知的是包含Open Data、欄位調整、能夠轉成Open Data登錄到國發會的平台，這個都是沒有成本的事情，所以理論上？

有成本，但是我們用既有的……

……（笑）你們可以吸收的程度。

我們會在今年的標案裡面處理，但是我們把原本現有調整的部分，我們會再處理，因為未來要作整合，所以有一些調整，我就變小幅調整，不要大幅調整。

OK，那這邊就這樣。

NCDR在沒有新的預算情況下，可以做哪一些事？

盡力而為。

你們剛剛說客製化可切入的版本？

沒有問題。

接著稍微檢視一下看起來太專業，縣市看得懂，民眾版作一些適度的刪減，並不是要你們加資料，而是減資料，這樣應該做得到吧？

可以，可以，沒問題。

既然做完規劃了，包括AP伺服器這一些，你們目前有在測自動擴充的什麼做法嗎？就是用什麼軟體？

我們那時做的是Azure上面做。

......就是用Azure auto scaling，可是那完全是私有的，也就是只有微軟可以用的，而且我們到最後也沒有要去用了，所以勢必要另起爐灶。

你們現在在Azure上面已經有一個Windows的映像檔，丟出去就可以跑，這個是AP、SQL......

單純AP而已。

還是連到你們本來的那一個ArcGIS伺服器？

那個時候的政策是國內的資料儘量不要放到國外去。

理解，理解，你們另外三個part，也都有做成映像檔嗎？

VM。

你們的建置方法都已經是VM建置了，所以理論上我們可以先測AP一次開十台或者是一次開五十台，或者是SQL一次開十台或者是五十台，他們之間對接會不會有問題，你們已經在Azure有測試過了，所以有Azure能力的平台，不需要花額外的錢的話，是可以測的？

對。

因此我的具體建議是：因為我們才剛拿到HGR的帳號、密碼，hinet現在有government region，因為他們異地備援還沒有做完，所以目前是免費使用，而且沒有上限、也沒有流量費的情況。

在這個情況下，我們是否可以至少拿AP之前在Azure測過的印象檔，先試試看HGR是否跑得起來，我們先確定這一件事。

如果沒有問題，災時用HGR擴充沒有問題，我們不一定投入production，但是未來在內政部機房或者是別的機房，你們這一套系統是有彈性的。

是可攜的。

可擴充的，並不是針對Azure寫的，這樣可以嗎？

單純針對AP那一塊，資料庫的部分，那牽涉比較多。

對，你們現在說災時需要彈性化也只有AP而已。

對，資料庫的部分，我們會把它轉移，也就是變成檔案的方式。

你們要攤平成JSON，也就是你們本來就要做，不需要HGR或者是Azure。

你們用現有的機器就可以攤平成檔案，這個是減少運算量用的，並不是增加，所以做完之後你們機器要少台，並不是多台的狀況。

攤平以後，還是要顧到攤平後的機器服務容量有多大。

是硬碟？

對。

硬碟的話，這邊也有一批免費的（笑）。

總之，攤平的工作你們本來就會做。延展性的部分，請跟PDIS的朋友們聯絡一下，看直接給你們帳號，或者你們給映像檔，看怎麼樣的作業方便。

但是至少測一下自動擴充，至少心裡有底，最後做出來的時候，也不用花資訊中心人員的心力幫你們打包，好不好？

我想我們可能近期要test一下，因為不容許出錯，他們會找我們算帳。

是啊！沒錯，當然。

你們之前在Azure的時候，沒有壓測過？

Azure測試過，但只是簡單的測試。

OK，好啊！反正趁著現在開幾台都還不算錢的情況下，我們盡可能壓測一下；所以經費下來以前，至少可以做到這一個程度。

非常感謝大家。