因為我們剛剛有講到一個是QR code一次授權的這一種方式，另外一個是藍牙的方式，在成本的考量上，其實大部分的考量不管是哪一個路線，其實都要新增添購設備，其實都是比較貴的。
尤其像在藍牙的部分，因為藍牙是一個開放讓人家連的東西，除了設備本身要增加成本之外，可能會遇到DDoS的問題，比如在院所候診的人故意要鬧他之類的，這邊有一個成本的考量，既然這一些即時連線跟寫入資料的成本與風險是高的，我們是不是乾脆考量不要寫入資料，完全使用雲端同步的這一種方式去走。
另外一個是，如果是手機搭NFC，而不要搭藍牙的方式，你的手機就要交出去，但是手機比健保有更多的隱私，這個是大家的顧慮，所以手機更不會交給別人。
剛剛講到如果你是完全走QR code的話，會有上傳雲端的問題。這邊會遇到一個問題，剛剛稍微釐清了一下，目前上傳雲端的問題，大家會認為是service收不下資料，我認為這個可能還要再釐清。
其中資料檢核與轉換的過程非常冗長，因此需要兩至三天才可以處理完資料，應該是這樣。
對於優待身分轉診、身心障礙役男寫進健保卡的考量，在成本的考量上覺得多寫這一些資料是非常有用的，可以減少很多多餘的人力支出。
這邊也是說要建立虛擬卡的流程，主要是要增加人力的流程及設備的購入，因此這一個部分其實也是一個比較不贊同的意見。
大概是這樣子。有沒有需要補充剛剛沒有講到的部分？喔！剛剛有討論到有沒有照片的問題，因為跟另外一組基本上是重疊的，因此法律面的意見，我們就沒有在這一塊討論 。
大家好，我是今天的助理主持人，我是Mark，等一下如果分組討論的話，我會負責一組的討論，等一下我就會把麥克風傳下去讓大家自我介紹。
大家可能會發現自己桌上有寫著名字的便利貼，如果方便的話，其實這麼多人大家講過之後就忘了，如果方便的話，是不是可以把便利貼貼在自己的胸前，大家交談的時候，就會知道你是誰。
不好意思，我稍微統整一下我這邊蒐集到的一些想法。
除了一開始有盤點到系統面該如何建置的問題要討論之外，早上又有提到其實有一些地方很重要，像如果發生誤報的時候該如何處理，這個部分也要在整個系統規劃的時候都有設想到。
另外剛剛也有一位先進有提到在電視速報上，其實有人會盯著它看，它不會跑，這個如何在電視地震速報上設計？
另外，剛剛有提到電視速報的環節太多、速度難以提升的這幾個面向。
下午的時候，我們可能會針對類似這樣的問題去做一些可能是概念或者是可行性的發想，今天剛好很多不同的專家都在場，有災防、電視、資訊系統的專家都在場，我們就可以針對這一方面來作一些發想。
在這之前，我想先確認一下，有沒有人想到有什麼問題，如果要在電視上發布地震速報的話，我們應該要考慮到哪一些面向？有什麼想法可以先提出來幫我們補充一下？謝謝。
我補充一下，因為我們分組的時候，會希望兩組都有不同單位的角色、立場，所以像提案人、附議人，我們會希望你們在不同組，NCC的幾位同伴，我們會希望你們拆成一半，不要到時候一組有內政部消防署的人，另外一組都沒有，這樣討論起來很奇怪。
等一下收東西的時候，可以想一下誰跟誰要一組，要到這邊或者是到另外一邊。
因為等一下我們會把桌子合併，私人的東西要收進包包裡面，稍微移動到比較旁邊的位置，我們會有工作人員協助作分組，謝謝。
兩組討論完、時間也差不多了，我們請兩組分享一下，剛剛討論的結果。
因為這個分享的時間可能會15至20分鐘，所以大家如果覺得腳酸可以找個地方靠一下或者是坐一下，沒有關係。
我們先請這一組的代表。
因為我剛好是這一組的，所以我就上面技術面的部分補充一下剛剛討論的脈絡。
比如說一開始的時候有討論到拉專線，大家都知道拉專線很貴，所以我們就快速放棄它，但是我們又聽說國中、小裡面都有裝程式、會接收預警，我就開始好奇了，這個國中、小到底幾秒會接收到預警，結果一講出來驚為天人，只要0.2秒，我們嚇了一跳，為什麼它會這麼快？
你不可能會拉專線到國中、小，我們發現是走網際網路，這樣很好啊！我們就copy這個模式到平台業者，就可以在平台業者，不用透過MSP，直接很快速地把訊息送到平台業者。
我們再繼續討探討的時候，發現原來應用程式只給震央的資訊，就是這個震央在哪裡、震度多少，所以送的資訊很少、可以送得很快。在各個電腦上的應用程式就會開始計算震央離這裡有多遠，S波推估是多少，因此計算這一台電腦的這個地方要不要發地震速報，其實地區性的計算時間是花在那一台客戶端的電腦上。
我們就想說這樣的模式是不是可以複製到機上盒，所以只要把應用程式裝在各平台的頭端，接上去之後就把訊息灑出去，然後可以計算距離震央多遠、要不要彈出字卡，第一次可以節省中央氣象局到平台的傳輸時間，因為計算的東西都不在平台上，所以平台也不會慢，平台又可以很快發到機上盒去，因為是自己算自己的，應該會比較快，算完之後就可以比較快彈出來。所以我們在這上面跟一開始原來指定頻道跟轉台的做法，我們少了指定頻道的節點跟轉臺的訊號，我們只是發訊號過去彈字卡，花的時間跟複雜度都是降低的。
技術的部分我先補充到這裡。
林雨蒼一邊在大家報告的時候，他就一邊做兩組的統整，因為兩組有比較相似的想法，我們可以看一下他統整的結果。
更正一下，是氣象局，這個credit要給對。
並不是機上盒自己抓中央氣象局，而是中央氣象局的應用程式裝在各平台的頭端，平台的頭端forward這個訊息到各機上盒上面去，然後把最需要花時間運算的部分放在各機上盒去算機上盒的位置、自己的震央離他多遠，它還是要透過頭端送到各機上盒上面去的。
是機上盒上面計算。其實這一個部分都有討論到，是要頭端計算或者是機上盒計算，如果頭端計算的話，一口氣要計算全臺灣收視戶的位置，這樣對他來講比較慢，不如把接到的訊息直接發送到機上盒上面去，讓機上盒自己算所在的位置，這樣可能反而會比較快。
是，除了計算震波到達的時間之外，還可以計算這個區域的震度有沒有到達應該要彈出字卡的標準。
我們聽起來的目的是要讓人猴衝突在網路上消失，這個才是目的？
這個是兩個問題。
還是題目可以訂成不要讓這兩個東西混為一談。
你說猴害的處理可以用降等來解決？
那個是廣義的猴害。
捕蜂捉蛇。
猴害要超過到農損的部分嗎？一廣泛出去就開花了，因為超多的。
如果反過來這樣講，因為我們現在不知道怎麼統計猴害，我們沒有一個方法可以去統計猴害造成的農損，所以我們協作會議的題目訂在我們一起思考如何發展這個東西。
現場一定有人提。
我補充一下，因為剛剛的題目跟一開始報告有很大的不同，所以基本上會打掉重來，這個只是我記錄的過程。
這個是簡報的內容，再右邊是農委會大PO講的內容，最後在我的畫面只剩下三張，也就是猴害再分支，要怎麼長要請大家提供資料，我們也要訪談一些相關的利害關係人、團體之後，才會知道下面實際上目前遇到的問題是什麼。
但是遇到的問題，其實常常有可能是，像已經有一個政策想要解決這個問題，但是沒有辦法完全解決，又或者是很多經驗是第一線的人才知道，平常可能不會講出來，或者其實有一直在喊這一件事。
不管是問題背後的問題或者是一個政策下去所沒有解決掉的部分盤點出來，然後在協作會議上討論。
是開始公告嗎？
另外一個想法是，我們也可以不要把它當成既成事實，為什麼猴子要不要降等跟討論猴害可能部分會有關係。
部分會有關係，但是也有一部分沒有關係。
對。
