大家好，很高興可以跟大家做這個checkpoint meeting，今天沒有要裁示什麼。

我們知道每一次到汛期、颱風出現的時候，院裡面就會想說，我們目前大眾可以看到的跟決策者可以看到的，比起去年有沒有什麼進步的地方？

因為我們在前瞻基礎建設裡，這個是大家都很關心的題目。

我主持的會議有一個好處，會有逐字紀錄，大家在分享的時候，我們會一面打下來，請大家在第一次發言的時候，先說一下怎麼稱呼。

我們並不是馬上公開出去，大家會收到email，這個mail裡面會有一個編輯的連結，所以不管是事後補充一些資料，或者是覺得有一些處於擬稿階段的討論不一定適合出去等等，都可以在共筆上編輯，十個工作天也就是兩個禮拜。

簡報的情況也是這樣，今天收到的簡報會對外公開，不過內容是可以抽換的。所以如果有簡報需要修改或者是抽掉的部分，同樣可以在兩個禮拜之內，可以讓我們的幕僚知道，在這樣的情況下，我們在公布的時候，大家覺得可以公布的版本出去。

這樣有一個好處，至少民間知道這一年來，大概做了哪一些事，如果接下來有一些民間的朋友們要做一些詢問的話，可以假設已經看過了，因為這一份東西出去之後，大概相關的利益關係社群大概都會上來看。

所以今天不是非常formal的會議，不用太擔心。

如果這個紀錄原則可以的話，直接進入報告事項。

政委、各位先進大家午安，現在先由我報告災防科技中心大眾及決策圖台服務精進的部分。

今天主要針對三個部分跟各位說明，首先是針對目標，以及到現在基礎服務建構的現況，另外一個是整個功能強化與精進的部分，我們跟大家說明。

首先，我們主要的目標希望有兩個，一個針對提供全民易都、易懂及易用的防災圖資，放在災害情報站，也就是提供一個圖台，在整個服務的部分可以提供相關的內容，讓全民可以透過這個圖台可以瞭解到目前的災害情勢及災情，可以讓全民查詢。

接著是決策補助的部分，我們希望能夠在EMIC 2.0裡面會提供一個決策的資訊，這個決策的資訊，目前正在建置，在EMIC 2.0裡面可以提供相關的服務，在EMIC於災害情資網提供使用的內容，可以讓使用者在裡面編輯及提供服務使用，這個是我們目前界定的兩個目標。

我們看到整個基礎服務建構的部分，我們把它分成兩個，一個是使用的族群來介紹，首先是針對大眾服務的部分，我們這邊考量到未來可以提供給更多人使用及所以我們在這邊導入自動規模化（Auto Scaling）的部分，在瞬間1萬人次，反映時間小於5秒。

可以看到下面的架構圖，主要的運用是HGR的政府雲，感謝政委之前提供我們測試，我們在去年已經可以服務相關的運用，所以今年就自己租用HGR的運用，因此我們整個架構，我們可以提供Auto Scaling的服務，目前已經架構完成，現正在微調，我們可以切換到這邊來提供服務，目前是用政委所提供的服務來運用，我們預計7月中可以獨立出來。

第二，有關於決策圖台的部分，這個部分我們是使用新竹的機房，而不使用政府雲？因為我們考量到有一些抉擇服務功能，GIS Server是用商用軟體來運用，因此考量到我們在過去survey的部分，也就是一個伺服器來做服務，效能會比較穩固，因此我們建議用實體的服務器來建構，我們會用相關的機會來放置伺服器。

現在已經購置完成，伺服器已經決標了，我們會陸續開始建置國網中心的伺服器，有AP server，我們會用DB，然後會用混搭的方式來做服務，最重要的目標是，如果可以介接到這邊來，就可以把相關的資料，透過GIS的伺服器變成圖像化，然後還有一個基本資料的儲存。

我們也會提供一個OpenAPI產製供應模組，我們可以提供後台來提供相關的服務，如果還有進階圖台的話，可以自己操作與整合，我們在這邊提供的是半成品的菜，使用者可以自己組裝、想要完成的內容來提供服務，這塊我們主要是提供防災的使用，因此不像大眾圖台的人數這麼多，有一些專業性的使用，瞬間服務人數是五千人，反映人時間時間數是5秒。

我們在去年開始提供服務，很感謝消防署幫我們蒐集到使用者的資訊，並提供需求給我們，所以在目標有做一些改進。第一個部分是我們希望能夠提供跨裝置的服務，因為很多人是用手機看相關的情資，我們那時還沒有考量到手機的使用，因此會擋到後面地圖的運用，因此使用者在看的時候很不方便，一些重要的情資會被擋住。

我們把文字的說明會會另外做一個頁籤，因此進來主要是看到一個頁籤的內容，在這邊查本身的地址，我們也可以用手機的定位，快速到你想要去的位置。如果點到圖例的話，會自動縮放，在圖台的設計跟文字的說明，我們未來就獨立開變成一個獨立的頁籤，因此可以透過這兩個方式來切換，是要看地圖或者是要怎麼切換使用，這個是我們今年希望逐步改進完成的部分。

另外，剛剛有提到的是，我們之前提供地址定位的部分，是單純讓使用者從縣市、鄉鎮都要完成的輸入，去年有使用者反映輸入的東西太多了，因此今年用縣市鄉鎮用下拉式選單來操作，這個是內政部的地址定位功能，輸入定位之後就可以快速輸入到想要的位置。

地址定位的內容，除了本身地址的位置，也會告訴你座標的資訊，這個是兩種座標，讓你做後續的使用，這個是第二個部分，也就是快速定位的資訊。

第三個部分，我們希望能夠把一些圖資儘量用儀表板化的方式來呈現，所以有一些資訊，我們在這邊使用燈號的方式，也就是每一個縣市都會用燈號來顯示，第一眼看是知道這裡面有顯示警戒的資訊，但是不知道是哪一種警戒，因此我們嘗試用儀表板，我們中心結合cda的資訊，用紅色就可以清楚瞭解到目前發布的警戒是哪一類的訊息，可以透過這個來點選。

我們可以再更細部的部分，可以知道詳細資訊的內容，像會有一個豪雨特報的內容，可以實際瞭解到發布警戒的資訊，這個是我們今年嘗試做的儀表板內容。

另外，在決策的圖台，我們在這邊希望能夠讓使用者可以回溯，我們跟消防署討論，過去有提出一個需求，現在看的大部分是即時性的資訊，有些針對災害事件，想要回顧當時發生什麼情況，因此我們希望能夠讓這整個圖台可以回溯到時間點去做書籤。

這個是決策或者是大眾？

是決策。

以決策為主？

對，大眾也有這個功能，現在是以決策為主。

現在是回溯到某個時間點，把相關的主題圖打開，有一些是看到動態的，也有一個動態播放的機制，是隨著時間再作移動，也就是可以更瞭解到整個情勢的發展。

製作完圖裡面，就可以回到大眾圖卡，因此不用設繁雜的功能，直接看結果，因此設計完之後就可以在這邊看到內容，因此我們希望在主題圖提供的服務。

另外，在決策圖台的部分，這個是我們希望能夠讓這整個使用者可以更快反映一些即時的現象，像消防署也有跟我們討論，也就是發生一個重大的災害，當時道路中斷時，希望瞭解到救災戶的情況，以前也許是紙本在上面點選或者是放旗子等等，希望做救災布署的調度圖，希望可以用圖例就點在上面，或者可以用繪圖的方式，也就是快速瞭解到整個救災布署的狀況，方便在這邊做操作使用。

也可以疊合現有的災情等等，也就是即時反映現況，可以看到文字資料的話，可以用繪圖的方式在這邊使用，這個是我們正在開發的功能，未來在這邊可以即時繪製救災布署圖，可以發布成一個API，EMIC等於做一個使用，這個是決策圖台設計的介面。

今年度我們初步設計的重點是剛剛所提到的，也就是大眾圖台及決策圖台的區塊，我們在7月中的部分，大眾圖台可以調降完成、並上線使用。國網的部分因為機櫃剛整理完，預計在年底可以架構起來，也就是決策出來的底圖，設計完成，也就是可以提高服務。

另外一個重點是前台展示跟後台管理的部分，我們這邊跟消防署與各部會一起合作，這個是易用的需求，也可以把龐大的資料可以圖像化呈現，可以不用看太多文字的資料，儘量用圖像化的方式呈現出來，也就是有空間的方式可以讓使用者快速瞭解到所有相關的情資。

我們這邊也有設計一個，為何要分大眾及決策？每一個人的需求是不一樣的，大眾是快速掌握瞭解快速的狀況，像消防署的需求是細緻操作的部分，我們可以依照不同的帳號進來，看到不同的東西，也可以看到不同的功能與操作，這個是我們在後台開始設計的監控管理後台的部分，以上說明。

謝謝。

我想分群是有必要的，但是之前我們大概這邊蒐集最多的需求主要是在實際進入救災狀態時，前、後台的事情不要有時間差，這個是最重要的，不然還有一邊是卡在以前的狀態，尤其在媒體上我們做訊息調度會比較困難。

剛剛提到好比像大眾版手機的，那個是你們自己開發嗎？

有委外。

有確定12月底要完成嗎？

對。

後台有做類似像書籤，比較像策展，可以提供前台去看？

對。

也是預計年底完成？

一年設一個標，今年有設一些工作項目。

所以去年沒有做完的前台Auto Scaling在7月中完成。其他的部分是以年底為目標？

是。

看老師有沒有要詢問的？

沒有。

感謝NCDR對災防資訊服務已經做了相當完整的服務，我有一個問題請教，未來大眾圖台資訊的揭露，請問是在應變中心開設的時期還是非災害的平時也有開設，又或者比如當下(現在)南部淹大水，其實已經淹了滿嚴重，像彰化鹿港已淹水約300公頃，像這樣的情況之下，是不是隨時開放的？

我瞭解一些災害，民眾是非常關心的災情，但是因為我們應變中心的開設是有一定的要件，像民生用水、停電，像最近很常停電，民眾會急於什麼時候修復。我的瞭解是在應變中心開設的時候，這個圖台才有公布，因為現在已經是自動化的介接，既然為了服務民眾、提供資訊，他們會非常想要瞭解，除了媒體記者之外，民眾會非常想要瞭解，我們家什麼時候可以修好？但是我瞭解應變中心開設的時候，可以取得這樣的資訊，但是如果沒有開設的話，是不是有這樣的服務？

我想請教有沒有擴大服務到平時（非應變中心開設時才提供災害情資）的可能？我不曉得我的理解有沒有錯誤或者是有問題？以上請教。

以我的理解，其實這個圖台的前端，隨時在EMIC的網站（http://www.emic.gov.tw/cht/index.php?），像水庫的水位顯示像白河、鹽水埤、東湧、菱湖、珠螺這幾個水庫有一些警示，這是不用開設應變中心就會顯示的。

但因為我現在看的這一頁也發現水利署的淹水警戒沒有介接過來，這應該不是前台的問題，應該是沒有後台資料。看有沒有什麼想法？

謝謝副主任的指教，介接都是即時介接的資訊，像剛剛有提到台電的部分，台電當初有說資訊就只有應變開設的時候才有提供，因此平常接觸到這個資料，因此顯示是空的，這個是跟部會搭配的。

部會提供的是資訊，我們也是提供即時的資訊，水庫的資訊是即時的，因此原則上會顯現出來。

剛剛有提到水利署淹水，大概10分鐘之內會更新一次，因為水的雨量在做更新，這個部分也許沒有看到，但是下一次就會出來，因此跟資訊不一樣就會不一樣。

是淹水的情境嗎？

應該是在豪大雨的情況都會有。

是給大眾嗎？

對。

台電可以要求或者是協調嗎？

我記得自來水公司跟台北市都反映很快，我們說要圖台的時候，他們說以即時更新為目的，我自己看了一下，確實這個時間差很短，但是台電一直協調到災時、一小時更新，但是平時不保證。目前的情況是這樣。

看大家有沒有什麼詢問或者是分享的？

我問一個很技術的問題，你們的Auto Scaling現在是買HGR，現在是按照實際流量收費，你剛剛提到最高到1萬人同時上線，那個是你們最多擴充到這樣，也就是有一個上限嗎？又或者是這個是為了省錢？因為理論上這個服務是沒有人數上限的。

今年先投入200萬在HGR這一塊，有一個量給我們。未來也不一定說是幾萬人，就可以擴張。

所以現在有一點類似像沙盒，最多花到200萬的情況，也不確定開到非常多台的時候，performance是怎麼樣，也許200萬就很多了？

對也許明年不用200萬。

對（笑）。如果是由決策系統算好圖，大部分是靜態檔案寫到HGR那邊，以這個預算做到瞬間1萬人以上，應該沒有太大的問題。

HGR那邊是放檔案的。

如果還好的話，我們就進下一個部分。

我們今天報告的是防災資訊系統後台資訊整合報告，本署這段時間與NCDR有密切合作，像需求或者是要開發的功能都有跟我們討論過，其實NCDR提供我們最好的美食，我們這邊是最直接受益的地方。

我們會先針對防災資訊系統，也就是NCDR所報告的，我們未來所要建立EMIC 2.0，我們會針對目標、策略，及NCDR後續圖台結合方式來介紹。

在目標這邊我們稍微提一下，政委剛提到EMIC 1.0汛期時候會被特別關注，因此我們會針對EMIC來做精進、改良及重新建置，因此我們的目標是要橫向與縱向來統整災害資訊並做即時傳達。

在新EMIC 2.0要導入Open API跟Open Data，我們希望蒐集到各方面的防災資訊，可以透過蒐集、彙整、訂定目標，能夠提供給外界來使用，不管是機關或者是民間團體。

其實在目標方面的話，我們在前台是希望做到一站式防救災的資訊推播服務，不管是災時或者是平時，我們都會透過防救災資訊，蒐集之後會給民眾做瀏覽的動作，希望他們可以得到最新的資訊。

其實第二個行動化的部分，其實在EMIC 2.0的部分是比較大的精進目標，剛剛NCDR有提到，我們能夠提供不同的媒體來做瀏覽的動作，其實能夠大大改善，我覺得應該可以提高滿多外界使用的欲望，如果不方便的話，未來要是比較能夠針對UI改善的話，民眾瀏覽的話，是可以大大增加使用的效率。

另外，剛剛提到救災，其實前台跟後台不能有時間差的落差，不管是行動化或者是現在這邊所提到的離線技術，都是希望能夠縮減彼此間前台與後台的時間差，像離線的發想，其實我們救災的時候，也許會有偏遠地區的收訊系統是有問題的，除了克服在地網路的連線狀況之外，我們系統能夠即時離線技術的話，在連線之後能夠對於資料上傳的話，也會有相當的幫助。

如同剛剛舒博所提到的，其實我們的前台展示跟後台結合其實跟EMIC整合目標是相似的，我們曾經跟政委報告過EMIC 2.0有四大策略及八大主軸，前兩大策略是剛剛所提到的以資料為主，資料彙整，也就是in put跟out put有了資料的價值，對於防災應變整合的服務可以加強。

第四，最大的策略是在於知識推廣演練，這個就不在今天討論的範圍內。

前面有提到EMIC簡單主要目標的描述，我們這邊簡單說明一下有關於圖台的計畫、資料與NCDR圖台的合作，其實2.0的規劃方案是自建地理平台，在成本考量及長官的建議之後 ，我們採用新的規劃方式，也就是NCDR的大眾與決策平台結合。

我們跟EMIC結合簡單的示意圖，我們有相關各式來源資料的匯流，我們做一個資料開放的共享，共享之後除了NCDR可以提供我們圖台的support之外，針對EMIC主要一些比較精進的服務，也都會有相當的幫助。

因此在EMIC、NCDR的圖台介接方式主要有兩個，一個是前台顯示的方式，其實在EMIC或者是災害情報站，我們會以iframe嵌入方式嵌入NCDR的圖台，其實針對圖台的操作、資料交換，我們就是透過API的介接或者是資料庫彼此間的連結異動來更新。

剛剛簡單示意圖上有提到我們在EMIC有幾個主要的特色，我這裡就挑出幾個跟圖台的特色拿出說明，有關於災防應變說明的部分，有針對EMIC被詬病的功能來做改善，有提送通報的傳送跟統計。

在動態視覺災情通報，希望可以即時接收報案資訊，我們希望改善原本的文字顯示，改以圖像的方式來改以視覺化的資訊揭露，因此在動態的視覺動態災情通報、災情影像服務方面，我們都希望跟NCDR的決策圖台來進行定位及分布圖的顯示。

其實NCDR也有提到可以提供給我們即時繪製相關圖台的功能，其實也對於指揮官的支援有support，針對圖像的蒐集並提供資訊給長官參考。

剛剛NCDR提到的是主題圖、時間軸，利用一些tag的方式把災情以時間軸的方式來作顯示，這個針對災情事件簿，也就是大事記的分類是有幫助的，剛剛有提到不管是資料的蒐集或者是彙整方面，這個部分就不再贅述。

剛剛提到我們跟NCDR圖台規劃的合作方式，接著要報告的是有關於資料匯流的規劃，其實我們在EMIC 1.0也有跟各個機關做資料的介接，其實後續我們目前2.0的規劃，除了本身EMIC所自產的資料之外，跟外機關的災防資訊，我們統一透過NCDR來取得。

這個是簡單的示意圖，EMIC自己產生的資料，災情資訊就是自己產製，各個機關的資料就是從NCDR這邊。

在EMIC有相當多的資料流，包含各位長官看到的投影片，我們有新北市、台北市來做案件資料的介接，還有119的資料介接，還有各業界填報資料的介接，透過EMIC資料彙整，可以透過Open API來供外界使用。

所以我們有一張表格來表示一下自行開發圖台跟使用NCDR圖台有一些不一樣的地方，其實我們最主要的概念是希望能夠統一圖台，希望能夠達到資料資源共享的方式，能夠減少他的資源浪費。

要是我們自行開發建置圖台的話，我們必須要做內部的系統程式建置，其實透過NCDR的圖台可以做嵌入、API的介接，其實是可以大大減少我們的勞力。

簡單提供我們的步驟，今年標案在7月底會招標出去，在今年底希望可以達到資料蒐集及策展的進度，明年、後年會影響災防系統的精進，像指揮官等等的進階服務。以上報告。

目前月底決標，沒有問題嗎？

還在公告中。

假設決標很順利，當然就很順利。這次和之前有一個很大的差別是以前不用進NCDR的圖台跟系統，現在在標案裡面是要接NCDR的系統。

我不曉得實務上你們覺得月底，或者是我們等月底再來看，或者是有什麼備案？

公告的時間是到7月中，因此希望7月中之後能夠有好消息。

OK，就是還有兩個禮拜的意思。

看老師有沒有詢問？

跟時程有關，今年底有辦理競賽，災害部分的資訊，我們很希望能夠直接有Open Data以API介接，如果可以順利完成的話，也就是7月底標案順利完成的話，我不曉得是不是有可能在兩個月內，廠商在開放資料的部分，也就是API的部分開發，按照過去跟他們接觸，他們的能力，是不是在9月中以前可以開始用機器對機器來介接目前EMIC 1.0的資料，我們直接可以做競賽使用？

「民生公共物聯網資料應用競賽」。預計什麼時候開始？

大概是8月中，很趕，我們要先給歷史資料，但是9月中希望給動態資料。

看一下第14頁，這個是EMIC理論上全部可以放出來的資料。

這個目前有的資料。

以比賽來講，目前就可以拿這一些去做，我聽起來在11月做的是匯流資料庫，除了這個之外，其他的EMIC還沒有變成資料要去做盤點，所以你們本來是抓……

11月。

可能有困難，一個是現有的……你的標案裡面，要開哪一些出來的規格有訂了嗎？

有。

這樣也可以用測試資料、模擬資料，因為畢竟這一些模擬資料都是在資料庫裡，理論上是可以撈得出來，是用手動做一小份出來，比如挑一個災害或者怎麼樣，拿那個整理出來是做得到，也就是如果需要的話。如果live的話，這幾個是沒有辦法。

9月要是Schema是可行的，但是做到技術方面是困難滿大的。

那就儘量從合成資料的角度去想。

我們聽起來NCDR過來是全部，他們有的你們這邊都要？

對。

反過來是這邊出去的API，然後NCDR收嗎？雙方是怎麼樣對流的情況？因為我看第13頁的圖非常地不清楚，出去的時候，可能要再重畫一下。看起來並不是左邊的都是NCDR，而右邊的媒體影像都是EMIC，你用了顏色，但是這個顏色並沒有什麼實質相關，因此我想再聽清楚一點，目前是兩邊各自給各自哪一些東西？

報告政委，從消防署那邊介接是從災情這邊為主，左下角這一塊會從消防署介接。

我們會提供給消防署利用，還是以API，也就是發布成圖像的部分給消防署。

紅色都是你們嗎？

對。

你們集成再給消防署嗎？

對。像災情有接CCTV，各單位都有接。

就一個API給他們，看他們怎麼用。這樣簡報換得比較少，兩邊的字樣對調就好。

這樣比較知道區別。

對，大家比較知道雙向拋什麼資料。

看其他有沒有什麼詢問或者是分享的？

兩個禮拜之後就會知道這一次招標的狀態，如果要討論備案的話，隨時歡迎聯絡我們辦公室。

因為民間之前的聲音是我們這邊開發很多功能，但是這一些功能相應的API其實沒有目錄出去。如果民間用爬網站的方法加值一下，好不容易寫好，但是網站可能又改版了。

所以我想API先行的概念很重要，我瞭解你們之前跟廠商合作時沒有這樣的規劃，會有一些衝擊，所以我想招標當中彼此有一些要磨合的地方。辛苦了。

有沒有要提出的部分？

不好意思，我想請問一下，剛剛蘇博有提到會把資料發布成圖像之後再轉到消防署，發布的意思是像之前那樣嗎？你們公開的是一個網址，而那個網址點開完整的網頁，然後嵌入在EMIC裡面。

那個網頁有帶原始的資料，如果可以的話，建議可以一併放在API目錄裡面，對於外面的人要介接資料比較方便，不用從網頁裡面拆解資料來源，直接從目錄中拿KML檔，會比較方便。

第二，我在看EMIC 2.0的時候，常常看到錯誤資料找不到的部分，想要詢問一下發生什麼事？

是正在轉機房嗎？或者是有什麼原因？

應該可以嘗試看看，未來有決策系統出的圖檔的話，那個是發布出來的服務，所以內容不侷限在KML，這個可能要套出來看要怎麼做。

其實我們發現滿多次，大部分是自來水公司的錯誤在那邊，那邊的編碼都是自來水公司，我們有跟自來水公司反映，剛好程式在修，有時突然資料沒有進來，就會出現錯誤。

不過我的意思，是可不可以在後台吸收掉？我們當初說要做數據資料，有一個原因是如果突然斷了，至少5分鐘前或者是1小時前的資料還可以用，不然使用者來看，就會跳一堆警訊出來，使用者經驗就不是很好。

有可能的話，是這邊的數據資料匯流上線的時候，可能要三個月，不然就是可以先用你們這邊大眾版的，決策先無所謂，也就是看大眾版的部分是不是可以先套區塊，然後先解決一下。

可以，先吸收掉，不要讓它出來。

API是需要雙方提供一個總目錄的什麼東西，因為目前我們知道資料品質結合在國發會那邊是用機器測可用性，不管是KML、CSV等等都沒有關係，只要寫清楚就可以了，還是以把描述資料上到data .gov.tw為目的，上到那邊的時候都去data.gov.tw去讀描述資料，描述資料儘量清楚，但是以上data.gov.tw為總索引。

看大家有沒有其他想要詢問或者是討論的？

大家記得在去年有一個在院會的demo，是給院長和秘書長的demo。

目前我們看起來是要等手機上線才有東西可以demo，不然就是多一些點位而已，事實上介面跟去年會是相同的。

手機這邊是12月底完成，還是……

手機應該可以稍微提早一點。

等時程比較確定就讓我們知道。

像之前報稅軟體案的做法，是不一定開這一種很正式的會議，可以錄3至5分鐘的影片，我們看起來沒有問題，就丟到YouTube上，這樣就可以了。

等到他可以做手機版的demo，你們也確定算是穩定，大家看了穩定之後，湧入2、3,000人而不會當機的情況，因為有時沒有災害，但是大家看到很新鮮就來玩一玩。

所以等HGR穩定，你們有初步的手機版可以demo的時候，就可以錄一個版本，就讓大家知道。

今天就先到這邊，謝謝大家。