其實只要3G還有開設，其實這些朋友就會去社群媒體報平安。現在我們這個其實不是讓民眾自己填，是讓收容所的人填？
好，謝謝，很清楚。
就是說目前事實上收容處所是不是已經有一個管理的，包含人數，事實上主要就是人數。也包含你剛剛說的要地方政府配合，這部分已經有人配合了嗎？
意思是說，他們很難出一個專職的人來去問每一個進來的人身分證字號，然後把它輸入進去？
所以目前其實已經有人用手抄，好比說身分證字號，但那張紙目前沒有到任何地方。
但如果人數已經是統計性的，他已經不涉個資，他為什麼不能接過來？
事實上是有嗎？EMIC裡面有人數資料？我們剛剛看沒有看到的原因，只是因為他前端沒有介面而已？
這樣我有聽懂。
剛剛葉副講一個觀念，與其精度非常高，但花非常多時間，不如寧可就是多個precision都不怎麼樣，但加起來還是知道狀況。
不曉得說，在這個案子裡面有沒有可能加進一些規劃，另一個是說在這個案子外，有沒有地方政府在做類似的嘗試。
要我找衛福部開會不是問題啊！重點是他來的時候你要有proposal給他，還是要有一個看起來願意合作的，至少一個地方縣市，願意跨部門合作。也包含他們那邊的承包方，跟其他的局處，對不對？
我們就找衛福部來開會啊！這應該不是什麼問題。現在就是說你們之前已經有過一個初版Proposal，包含那個行李箱。
這個不一定要綁入特別預算，我們拿公務預算也是有空間。
而且如果是試做的話，他成本並不是非常高，所以想說你們被拿掉那一段看是不是先寄給我。我先把它看懂，然後技術上我覺得沒有太大問題的話，可能就另案跟衛福部討論這個部分，作為一個實驗性質的處理方法。這樣也比較沒有明年五月一定要交卷的壓力，這個我想對大家也都是個壓力，所以我們把它切開來做，但我想這個還是值得去做。
因為如果已知卡在這邊的話，現在技術成本已經非常低了，我們也不能像以前等技術成本更低來作為藉口，現在沒有這個藉口可以用了，從民間看起來明明可以做的為什麼不做。以前我們還可以說太貴了，現在說太貴了外面是不接受的。
接下來就是定期改版這件事情，剛剛也有講說，汛期前上版，到冬天的時候做壓力測試。這是不是固定的時間點；如果是固定的，就明確的寫進RFP裡面，就是固定每年兩次或三次可以動系統的時間。
下一個第9個是在講分析的功能，剛才我們講的一堆資料的接取，如果有第三方或是NCDR這邊，或是學界，做了一些分析，見了一些模型，在這邊是不是有一個開口可以讓各地方政府或是民眾，接取這些分析。
這其實就像國發會的開放資料平台，他有一區放資料活化應用。意思就是說拿開放資料做活化應用的話，可以跟國發會申請說，我要把活化應用登在其中的某一區，讓其他人也可以來看這個資料的活化應用。可能是一個很簡單的可以掛分析的地方，不曉得這邊有沒有覺得困難或是需要討論更清楚的部分。
基本上就是說如果已經是Open Data或OpenAPI 就直接掛載data.gov.tw上，如果有第三方拿這些去做應用的話，本來就有一個可以掛分析的地方。那我們未來在APP上或是網站上，怎麼樣在接近來，就看實際有活化應用出現的時候，我們來看這些分析服務可以放在介面的哪裡。
救災雲賡續計畫，是服務型智慧政府，還是智慧型服務政府，我從來沒有很記得。S2G裡面的計畫跟我們特別預算的關係，不曉得...
意思是說他們是獨立的，沒有什麼路徑相依性。
我的意思是說，沒有一定要這邊交前瞻那邊才能做，或是前瞻一定要做到什麼程度這邊才能做，是獨立的兩個計畫。機房的部分，不是用內政部的嗎？
意思是說也沒有白買，舊機器搬過去，還是是說其實有白買？
那就麻煩真的要整體規劃（笑）。不然就會出現賡續買的機器卻沒有用的情況。這部分沒有太大的問題。
剛剛講到運算平台，不管向上級中，放在東七或HGR。在公共民生物聯網總綱，只少要放一份應設在國網。這部分有任何困難或問題嗎？
我想這個就是資料跟API目錄做出來的話，用統一的方式介接。最大的問題是要測瞬間流量，這個我覺得也還好。國網硬碟幾乎是不用錢的（笑），即使用motion jpeg應該也是放得下－－這是為什麼當初到國網（的原因）。
接下來是，災防辦這邊提到的我們在分類裡面，對於防檢局的疫災，跟颱風地震無關的海難空難，這些態樣，是否在上面有呈現的方式？
簡單來講，希望未來有個自訂災害模組的功能。自訂災害模組應該是讓領域專家定義，而不是我們現在對疫災或其他來定義。能夠自訂災害模組的部分，是規劃在四年期對不對？是在前瞻裡面把它做完嗎？還是沒有？
就是我們能夠承諾的是四年之內把颱風跟地震，弄到颱風歸颱風，地震歸地震，其他災害模組要四年以後再來討論，意思是這樣嗎？這樣可以接受嗎（笑）？
這邊講的就是說，前後端分離。後端我們理解到不會一下子出現到海難空難模組，但前端是否有可能讓別的後端，用這個東西來當作呈現的方式。
我們這邊需要做的其實就是把我們相關部分前端的程式碼或是API的接口，提供給航港局或防檢局，告訴他們說如果要串接的話要準備怎麼樣格式的資料。除此之外，我們也沒有辦法，因為我們真的沒有那麼懂。
（即使）沒有辦法提供後端應該怎麼寫，但是至少後端只要改成這個資料格式，那我們前端可以幫忙呈現。這邊希望的是這樣？到這個程度應該還好吧？
這個就會變主要維護還是航港、防檢在維護，但是新聞暨這上來的時候還是可以在這邊看到最新的災害情況，這樣子。但是我們這邊就不再後端去做開設或是派工，這樣可以嗎？這個程度。
這個程度，我們是兩年期？還是四年期？（笑）把它做出來。
好，回去討論一下，但這個我相信，至少四年期。
我們把它當作一個目標，這個我覺得還滿重要的。因為未來隨著系統功能越來越強，其他的公共民生物聯網裡面，凡是達到接近災害等級的時候，甚至包含嚴重的空氣
品質或水污染或地震速報，這些東西一定都會提出相同的需求，就是後端我們自己管，但是前端可以在這邊呈現。
所以我想這個是要綜合考量的，我覺得是很值得放到我們的範圍裡面。
接下來就是風災的時候，海運跟空運的服務中斷，這個目前我們是否有所介接，前端是否有顯示的方式。先不管公路或是CCTV，好比像說有一些航空公司停飛，或是班機延遲這些也都有結構化資訊，但是我們目前是否有顯示的方法？
這句話後面的意思就是說，如果他們有這邊就可以接？其實是他們有沒有符合我剛剛講的公開介接格式，之前我們這邊不會廣為宣傳，你要符合某個格式我們就可以接。但未來至少為有一個技術文件在那邊，這樣我們也須再分別請交通部那邊，能不能夠產出符合這個結構的東西？
基本上我們原則就跟之前討論一樣，如果是手寫或口頭描述，我們不負責猜他們意思；但是他們願意用結構化方式提供，我們這邊都可以顯示。
那接下來14，14這些也是我自己感興趣的，就是說我們現在在目前的這個災時已經接NCDR的資料。但是我在平時，目前沒有接。但目前沒有接的好處是說，我們可以顯示某個災害已經處理完畢，或是顯示一些對新聞媒體比較有用而不是很早以前發生的事情這樣。
在EMIC的首頁，這部分是不是有相關的規劃？據說當某件事情處理完畢之後是不是就在EMIC，災時轉平時的時候，那個平時能不能更清楚的講說什麼災害已經過去了，而不是看起來都是之前的災害這樣子。
我們有個首頁，有很大的Banner，有點像是手風琴那樣子的介面。
這邊的意思說我們不要追著媒體，我們可以自己當媒體啊。EMIC的首頁他也是一個媒體，對不對？
這樣聽起來你們目前主動推送的方式就是LINE群組，可是就是說不在那個LINE群組的人，他知道你們跟媒體講了什麼？我的意思是說這個最新訊息跟LINE是同步的嗎？
就是說我們用最古老的RSS好了，是不是在即時訊息公告的右邊，有RSS黃色的按鈕，按了就可以自動取得目前的即時訊息。當然不想用RSS或是用atom什麼都沒有意見拉，重點是讓他們容易去取得，去串接這樣子。
我不反對用LINE，但是如果有一個公開的，在上面大家都可以看到的。我們就先講RSS好了，這樣的東西的話。大部分的媒體都有接RSS的能力，這個協定存在非常久了。是不是不怕人知道，只怕人不知道這些事情，盡量用RSS的方式。那這樣才不會說這個記者雖然在LINE群組裡，可是上搞的是另一個記者，靠人工中間還是會斷。
我們跟電視台建立自動介接的可能性的話，就跟中選會開票一樣，沒有接上的媒體他們會有自己的壓力，會覺得說我Lag了；但是在此之前我們還是需要一個公開而不是LINE群組的地方，哪怕是資料完全一樣我想都沒有關係。
正在看逐字稿的媒體同仁（笑），剛才這句話的意思是：我們提供充分事實上的訊息，讓大家不用在做調查報告，就可以在做更多加值的新聞工作。我覺得這是一個非常好的想法。
