我可以這樣講嗎？這樣會很困難嗎？
一堆路段的東西都是點在同一個點上，首先畫面上看起來就很奇怪了，點的時候會真的蓋掉那些實際有點的位置，這樣的Open Data，我們實際做的時候做很多清洗的工作，我會希望還是把至少那一個fuzziness把它標出來，這樣我們在清洗的時候，至少知道哪一些該清洗，這一些沒有清的話，最好不要直接放界面之類的。
我覺得還是需要提示耶！我不是說提示的精確度都要到多精細，我可以接受同一行政區、同一縣市的誤差範圍，但是還是需要一個精確度標籤，不然的話，我們再做plotting的時候會非常困難。
但是我現在從data.gov.tw的資料集裡面看不到，等於是要用heuristic去猜。
但是如果沒有搬動它，你應該可以多一個欄位說fuzzy取出來的之類的。
喔！如果行政區都落在中心點，你可以知道落在中心點就是錯的。
對，我的意思是，臺灣的縣市中心點就是那幾個。
放在中心點的時候，我們可不可以給他一個資料品質，好比像誤差值之類的，讓大家知道這個是猜出來的？
所以我的意思是說，如果要增加geo data的可信度，你會覺得怎麼做比較好？
可是這樣子就造成我們不知道哪一些是系統在介接的時候的問題，也就是這個系統本身就沒有給出好的資料、更新資料，哪一些是使用者習慣不好，我們都沒有在追。
理解，我看到即使用線段都是少數的，面只有十一筆，事實上大部分的人沒有很把它當一回事。
有一點像是當作簡訊集成平台在用，那個地理資訊只是碰巧有，壞掉也無所謂，這樣嗎（笑）？
對。
甚至訂錯，他們也不care。
好比機器對機器對接，這邊我只要檢測出兩筆錯的，我整包給你拒絕掉，然後限你什麼時候改善或之類的，就是不能往上游要求嗎？
所以我的意思是，資料可用性的這一件事，難道我們不能回過頭要求嗎？
我如果真的要這樣plot，點會長這樣。就是地址不在門牌資料庫，也就是新的區段或者是區域重新劃分，這個是最常見的狀況。
可是這個資料的可用性真的（笑）……就是說我如果現在不是看通報，而是要plot一個在GIS圖上的話，我就會看到市中心出現一大堆事情，然後在道路大的轉折點上出一大堆事情，道路中間什麼事情都沒有，對不對？
這就是為什麼我看到一堆經緯度一樣，但是地址不一樣的資料（笑）。
……喔！M2M的時候。
……定不到的時候，你應該退件，告訴使用者沒填或者是定不到。
對啊！
就是說如果經緯度在臺灣外面，這樣真的對嗎？
對，就是選零分零秒，你不能說零分零秒錯，就好像經緯度你不能說（0,0）錯……等一下，其實經緯度真的沒有道理不檢查啊（笑）！
時間有。但是如果它登打的時候，是登打十分鐘以前的事，像我剛剛看到都是在整點以前發生的，這個我們也不能管它的。
還有整包匯入的部分，我剛剛聽到的是說，只有大概十分之一左右是機器對機器匯入，其他都是手動的後台系統去登打，這一件事不管是手動登打或者是機器匯入，目前的資料正確性及一致性的這一些檢測都比較少，就是說如果一個路段毀損，然後一個點在台灣外面，或者是不小心回到未來，我們都沒有在管它？
請看是不是能夠幫忙評估一下，看會花多少力氣做這一件事，大概是這樣。這個是整包匯出的部分。
如果都用Open Data的話，我們就用標準國發會Open Data資料檢測的程序來做就可以了。
所以如果資料品質壞了，除非像我剛才點到，剛好看到這一筆沒有出來，我也不知道是不是因為它壞了，或者是那部分其實沒有資料，其實是無法區別的。
因為這一種私有的API，最怕就是你只有Word的documentation，當下一手要接管的時候，根本不知道要怎麼管，也沒有往Open Data讓不特定的第三方來保證資料品質。
最可能的做法，是這邊有沒有任何的資料是Open Data沒有給的，我們這邊就全部轉成Open Data，這樣我們才有足夠好的理由跟consumer說：「你們讀Open Data就好，不要再用這個API，這個API要慢慢廢掉。」
第二件事，我聽起來機器整包匯出，就是往Open Data的這個部分，目前有兩個。一個是往Open Data，一個是往EMIC.gov.tw，有使用者看一次，就撈一次的Web Service，這兩個其實並沒有道理是不一致的。
因為最近沒有太大的災害，所以先測測看，這樣我們才知道是哪一層會出問題，這個是一件事。
所以，如果有可能的話，有沒有可能把它提到梅姬颱風區分的……各系統分配到的壓測百分比還是一樣，但是總數變兩倍或者五倍，然後去看一下它的天花板到底在哪裡，如果有可能的話。
但是如果比梅姬颱風大的用量底下，我們其實目前沒有那麼確定裡面的某些單獨的元件會發生哪一些事情，按照剛剛壓測的那個數字來看。
我聽到的是，我們先從功能面來講，就是說EMIC目前的功能是正常的，假設不要比梅姬颱風大的情況下，它是可以運作無虞的。
所以大方向，我綜整一下我剛剛聽到的，如果綜整有問題的話，不管哪一邊都跟我講一下。
好，我們自己寫（笑），這樣我大概瞭解，謝謝。
這一件事發生的時候，會需要往下call你們的API，叫他多開一台機器，目前有沒有機關或者任何使用者已經這樣在用？
它已經快要用完的時候，我就旁邊再開一個，因為container可以有一個running snapshot，所以丟過去又繼續跑，等於這個VM層往上用軟體在做一個container虛擬層。
好比像Amazon EC2好了，好比我們通常做container virtualization的話，如果是Linux的話，可以一台八個vCPU，但是事實上它算成可能十五台container都丟在它裡面。
所以Cloud BOSS目前有driver可以更高一層abstraction，不管是Kubernetes或者是Docker Machine或者是什麼東西去drive它嗎？
就跟任何的provider一樣？
如果這個並不是mission critical system或者大部分是read only系統的話，其實用GCE或者是用EC2或者隨便用哪裡都沒差嘛？
即使你們推出了這個，是大家一定都會來買Government Region，還是有些用HiCloud就好了？
都是在測試的階段？
只是在production system上，你們還沒有合作的機關？
功能是一致的？
所以有沒有機關單獨在你們Cloud BOSS可以跑的情況下，自己先跑來做elastic deployment？用公有雲做嗎？
