總之，這邊存在另外一組人，NCDR，他們自己會寫程式，不需要找廠商，所以他們就常常收到地方政府的一些需求……
可能還沒有那麼快討論這個，只是先理解實際狀況。
這個是我們下午會知道的事情。
不是，EMIC一定要有啦！只是「N到1到M」的訊息轉送那一部分，一次災害，現在通常都是送個位數，有的時候根本沒有送到「M」。
以上是EMIC的故事。
這是有一個圖台的，理論上在後台是可以用疊圖的方式放上去，但是從民眾的角度來看，並沒有任何類似這樣子的東西。
院長上次不是很滿意，因為發現台水、台電的「N」沒有完全接過來，而且最大的問題就是，有接過來的部份，還要自己在腦裡看著地址去還原到圖上，就是跟颱風動態圖完全沒有對應。
但是事實上不是，就是遭到了bypass，有些資訊來源自己先對外，之後再來EMIC登錄。
這個所謂的「災防雲」，就是message bus，所有關於災害的資訊都在這裡，所以要做任何事後分析跟ETL，這邊等於是最全的資料。
總之，「N到1到M」，我上次問說如果把這一個轉送的服務整個抽掉，會對下一次颱風有什麼影響，消防署的人想一想說沒有什麼影響（笑）。
另外一件事是，從「M」的角度來看，有些會跟這一個「1」收滿多錢的，簡訊也好或者是其他東西也好，這邊都要花不少錢，才能發到「M」去，反而地方縣市的話，跟「M」有時候談到更好的條件，地方縣市的消防局這些，當然是最大的「N」，當最大的「N」都已經直接跟「M」結合了，「1」的意義就變得非常小，對「M」來講，不接這個「1」，也接得到「N」。
第一，「N」往「1」的部分沒有那麼結構化，基本上就是你們看到的這樣，所以如果「N」跟「M」都希望要結構化資料，他們並沒有辦法說我的EMIC裡面包一個JSON，然後來收geotag或什麼別的東西，所以「N」就會直接跟「M」講了，因為EMIC沒有什麼用。
實際建置出來之後就發現，那一些「N」根本不理它，自己還是去跟「M」聊，為什麼「N」還是繼續跟「M」聊有幾個原因：
對。但是當時建立這一個系統，原因是希望EMIC系統是「N到1到M」的系統，意思就是台電也好、誰也好，只要到這裡就可以作必要的轉發，在發送的時候就可以說想要誰知道，或者是在這邊自己判斷這個有用，我還要另外轉發給誰。
那當然。
我們看到水電維生管線這一欄是空的，事實上當時真的有發生，只是不知道因為格式沒有接好還是什麼原因，所以沒有從台電、台水那邊接到圖台來。
總之，我們這次的business requirement是這樣的：上一次風災的時候，林全院長去視察，然後發現說道路斷掉的資訊、停水的資訊及停電的資訊，它沒有辦法接過來到地理資訊界面。
當然在發生好比像颱風的時候，會有從氣象局那邊來的颱風動態圖，會把他收到的這一些hub裡面的東西，然後按照跟這個災害最相關的tag，但是我不確定是tag或者是income source去作分類，所以你會看到一個類似dashboard的東西。
像震災，震災就很大了，不是嗎？同樣的也有補助、服務措施，所以簡單來講，就是維護一個非常類似hackfoldr的東西，結構上高達九成九相像的東西，而它的主要資料就是有時間碼的HTML。
沒有耶！其實這區都不是自動的，是人去上稿。
反正就是長這樣。
然後下方會把所有相關的朋友們受到的訊息通通都po在這裡，我們發現目前收到了兩則，全部就這樣，這就是人類可見的部分。
這裡我們就會發現說，首先會用純文字，這裡可以看到，它也不是很結構化的資料，只能知道大概是怎麼回事。
他當然也有一些大眾可以看的界面，所以如果我們到EMIC網站的話，就可以看到他們事實上是有外面可以看的界面，不只是後端的東西，就是不只有管理界面。
總之，這個系統其實概念上非常簡單，就是集成跟所有災防有關的資訊，他們通通丟到DB裡面去，再給有不同權限的人登入之後，從後台去察看跟他有關的部分，然後分發給地方政府、民眾或者一些CBS之類的，也都可以訂閱說我想要哪一些特定的訊息。
這一個系統是NEC在營運，但是後來因為portal.EMIC.gov.tw登入的部分performance不是很好，所以那部分請中華電去調校了。
EMIC以我的理解，消防署有權去主動通知大家、通知其他機關現在發生了什麼災害，然後災害的搶救狀況、前進指揮所的朋友上來登錄災情，這一條線的上半部是他的系統。
當時我只是跟他討論一些設計上的考量，沒有提到消防署跟災防中心的兩個系統，但是我們在大略瞭解系統前提的情況下，無論如何還是設計出來了，今天我們只是再次快速走一遍，確定這個圖還是正確的。
這一張圖，是Rufus Pollock上次來這邊的時候，我們一起腦力激蕩出的一張圖。
好，那全部就是這樣子，謝謝大家。
既然現在說Oracle都不加在新的這一區裡面了，就像剛才顧問說的，我們也可以問Google彰濱機房的報價，看公有雲能不能用，這都是可以調配的。
所以我想這個就是先測測看，我們測到一個程度再回來算這一個事情。
最後關於elastic機房的部分，我實際測HGR開機要多久之前，其實很難有一個很精確架構的預估。
所以如果手機的界面，跟server中間的聯繫不要用API之外的管道，這樣我們可不可以說RWD就往API first的方向來設計，ZK就放著，反正桌面可以繼續用，這樣可以嗎？
依你們現在的寫法，Server只要一出HTML，未來手機的大小改變，或馬上要變成一些新的display出來的時候，你還要再改後端。
我剛剛是說今年以讀取為主，但未來寫入、登打也要做，所以這個東西，是不是一次設計的時候，就把它設計成API first，也就是API進、API出，然後不管是手機或者是別的，只可以用client-side ，不可以用server-side HTML畫界面，也就是server不要出HTML。
這樣的話，我想問說RWD，你們ZK測過之後，ZK升版之後，也不會自動變成RWD，這樣勢必要重新設計。
所以這個也有想進去？
至少把那一句話，語音輸入進去了，經緯度至少不會錯，因為他人在現場，其他回來慢慢改？
就像有點民眾的那一個，只有三欄或者是四欄的狀況。
有困難的，因為我看那一頁要捲動。
登打的部分不需要那麼在手機版？
所以是閱讀？
OK，你們在規劃手機版的時候，我的想像是要照顧在那一些前線用的人，因為如果都到應變中心就有桌機了，打字比較快了，所以當初要做手機版，難道不是為了輸入嗎？還是為了讀取，輸入不是那麼重要？手機想像的用法是什麼？
如果我要拖大頭針是最快的，也就是災害發生跟登打比選行政區來講，我只要做一個geo position就知道我人所在的行政區，所以那是前線人員在登打，那個大頭針比較容易準，或者其實也不是，登打的通常都是坐在辦公室裡面，畢竟離前線非常遠了。
所以目前他的檢核有透過HTML5的API去抓電腦在的位置？
……理解啊！所以我們剛剛是說就不檢核了，是這邊的可用度再加一個標記而已。
同意。
同意啊！
對，是人key。
