準時開始，非常感謝，我們直接進簡報。

政委、蕭主任、PDIS小組、農委會及署裡面的同仁、資拓宏宇公司，大家午安。

先跟政委報告一下，原本林組長也要過來，臨時被署長派去農委會，開國家永續發展委員會裡面的永續多樣性……那個名稱很長，他去開那個會，所以就不便過來，比較不好意思。

沒問題，他可以看逐字稿。

接下來的部分，我就產銷資訊組合的部分跟大家報告。

今天報告的內容會分三塊：

一個是整個產銷資訊相關資料開放辦理情形的部分，這個部分跟PDIS小組都有聯繫，要針對哪一些要去開放，這個是3月3日政委指示要開放的資料之辦理情形。

第二個，「6＋1」分析圖表，我們自己原來規劃作產銷資訊分析，也要做署裡面決策資源support跟開放資料情形的部分。

第三個，有關於系統運作及展現的部分，我們有一些想法及規劃的做法。

（簡報第3頁）這個有分成幾個資料的面向，第一個是在農委會這邊開放平台的部分，這個就是跟我們署裡面比較相關，第一個是批發市場的量價，在Open Data裡面是數字最大的一塊，從80幾年到現在有四百多案底，這個本來就已經開放了，所以這一個部分的資料有miss，不只三年的資料，所以這部分的資料量滿多的。

接著是產量推估的部分，本來是公開在署裡面的，那部分沒有Open Data上去，這個系統本來是每一個月預測的，只是一個Excel檔抓到的資料，我們有抓到這邊來，再放到Open Data上去，所以這個也是產量推估的部分。

再來是滾動倉貯，這並不是整年都有的資料，而是汛期5月開始，也要看作物的品項，也許5月啟動，或者是到6月也不一定，啟動之後才會有滾動倉貯的資料。3月3日的會議有討論到當天的資料不方便給，隔天才會給，這個也會在平台建置完成之後，才會到開放平台，這個是會裡面自己可以掌握資料的部分。

第二個部分，有關於氣象的資料，氣象局很早就放上去了，這個已經開放了，資拓公司跟資訊局一直有聯繫，包括雨量等資料都有放上去，都已在開放平台上了，這個部分我們也有接下來。

（簡報第4頁）接著是零售市場的部分，這個有一點棘手，那時我們看的是北（台北）、中（台中）、南（高雄）的零售市場資料，高雄的零售市場到3月3日有開會，動作很快，回去馬上處理了，回去就把資料丟上去，因此這部分的資料也已經丟上去了，本來只有丟當日的，因這樣不夠，也把歷史資料丟上來，因此後來也配合把3年的歷史資料丟上來。

現在比較有狀況的是台中跟台北市的部分，因為我們都有函給這三個市政府，而回來的情況是，因為批發市場跟零售市場在這一個交易的方式，基本上不太一樣，因此資料蒐集的過程不太一樣，批發市場進到批發市場來，每一筆都要拍賣，因此會有價跟量結合，均價、上價、及下價都會有rule計算出來。

批發市場並不是這樣，像賣高麗菜有五十攤，不可能每攤問下來，不會的，但是並不會記錄量，因為交易的模式不一樣，因此同一個高麗菜或者是甘藍，在高雄市的零售市場可能有十五個小在地市場，可能有國民市場或鹽埕區市場之類的，鹽埕區市場的高麗菜價格僅是一個，因此在資料的取得上不像批發市場嚴謹，因此不開放的理由很大的原因是，（此價）並不是去問平均（價格），而是抽點的價格，因此認為以部分的價格來代表全部的話，可能會讓民眾誤用或誤認，有人來買菜的時候，原本鹽埕區是20元、這邊為何賣30元，（事實上）因為品質不一樣、來源不一樣，價格就會有差，因此，台北、台中不開放的很大原因是如此。

不好意思打斷。

像當時你們說滾動倉貯不宜公開，以免影響市價的時候，我們腦裡公開的是或許一年前的沒有問題，但是討論之後公開昨天的就沒有問題了。

因為台北、台中看起來理由是相同的，應該是說台中的理由跟台北的前兩點是一樣的。所以我現在想問的是三個問題，我們逐點來看：

第一，如果第一個是抽樣，而不是普查，是不是有可能在資料的標示上就明確地說這個是抽樣價格之類的？能否有一個、兩個市政府接受的字樣，讓大家知道這並不是平均、統計，只是抽查的結果，這是第一個詢問。

第二，我們知道取樣的範圍是有限的，但是取樣範圍有限，好比像在一天之後或者是兩天之後，就不會有干擾市場價格的問題；也就是說，即使是有限的抽查，長期看來，在統計上是有意義的，因此現在的目的只是不要影響到市場的交易。是否能夠給一段時間？好比是一天或七天或者是十五天的資料，這樣他們就覺得ok，但是我們做趨勢分析還是有意義。

第三，只有台北提出來，「易衍生消費者與攤商間的糾紛」，這個哪一些是我們可以透過更改標示或者是更新的時間就可以解決的？哪一些是即使我們這兩個都明確標明，而且也是釋出舊資料，他們還預見無法解決的？如果有這樣的情況，為何高雄沒有出現類似的糾紛？這個是可以追問的，第三個不需要馬上就問，但是我們還是要回一下這一個函。

他們以為我們的呈現跟實際上的呈現其實有一點落差，也就是我們並不是馬上要變成一個……我覺得這樣回函的想像是，我們把它像一個電商一樣，像買貴退錢或者是保證最低價這一類廣告性質的東西再使用，這樣會引起糾紛，我們的介面並不是這樣性質的東西，當然如果能夠減輕這樣疑慮的話，我們很願意再標示跟時間差上配合。

當然這兩個之外還有想像到其他的態樣，高雄也會受影響，這個時候應該要知道。

這個部分我們會再跟台北、台中市政府討論。

誠如政委的指示，因為還要回函，因此是不是有標示、時間差，來做妥善處理，看有沒有進一步的其他困難，我們再來協助處理。

所以這兩個資料可能會比較慢一點。

接著是進口量的部分，我們有跟關務署談定，我們在3月17日有跟關務署研商，他們也滿配合可以提供給我們，本來關務署提供旬、日的資料，我們是第一個要月的資料，他們也會follow，他們也會給月的資料模式，我們再從農委會接過來使用；這部分是4月中旬會把程式用完，因此後端接過來應該可以滿快來作處理。

（簡報第5頁）這一些資料抓回來之後，前端菜價資訊公開平台的部分，要取這一些資料，我們會用API的方式來處理，這一些資料的面向、項目有列出來是至少有七項，這裡預估的API數目，只是預估，還會有所調整，總共是二十七項，目前完成十二項。

（簡報第6頁）這邊是供用面、零售市場的部分，供用面看起來比較算是氣象群組裡面，規劃在哪一類可能沒有那麼大的差別。

（簡報第7頁）這是到時候會展現前台給民眾查詢的畫面，左邊是查詢條件，裡面有一些維度及查詢的條件，第一個是時間的選擇，接著我們覺得條件非常多，對使用者也不是那麼方便，因此在日期選擇的部分，我們讓它選到「月」就好，因為選到「月」就可以展開選到「日」，就不用選到那麼多。

像氣象的部分，在氣象局總共有八百多個測站，就分了縣市鄉鎮，可以讓使用者選，接著是零售端的量的部分，這裡也會選品項，也就是哪一個地區的、哪一個零售市場，在上面都可以選。

接著是推估產量，雖然這邊沒有展開，推估產量因為維度前面就有了，因此推估的是「產量」。接著是地區，看是哪一個地區。接著是滾動倉貯，而滾動倉貯沒有地區別，這一個作物釋出多少，基本上就釋出到批發市場去，並不會到別的通路（如家樂福等）。批發市場主要是台北一、二市。

在作物品項或者是農產品項的部分，我們沒有把農產品項提出來當作common的條件，我們去做這樣分析的時候，當然會想說要比甘藍，大家都來比甘藍，這個是很common的想法，我們就會放到common的條件去查詢，這個是開放到每一個資料項目，也就是在零售市場，可能選了叫做「青蔥」，我在批發市場，可以選別的作物，當然一般會想說有人這樣比嗎？不一定，也有人這樣比，因此我們把討論做得比較活一點，可以做多維度跟交岔分析比對之類的，這樣的設計是這樣的情境。

（簡報第8頁）剛剛都是講Open的部分，我們本來是做資訊整合分析圖（6＋1）的部分，在3月3日的會議當中我們說明了使用的情境，只是有一些已經設計完成了，有一些可能還沒有，已完成的部分，大概可以看到查詢展現的方式及意見怎麼樣。

請點到「項次1」的連結，（簡報第12頁）這個是已經大部分完成的，還有一點沒有完成的是，像黑色的「背景值」，我們是用所有批發市場之過去三年的交易量價，前幾天我們副署長有指示我們在做分析的時候，應該用全國，因為柱狀圖是我們推估的產量，也就是以全國消費為標的，所以背景值應該也要用推估全國的量，因此這一個參數還會調整。

通常批發市場佔全國的消費量是三成五至四成左右，因此這個參數還要再納入調整，因此我們推估之後，也就是生產面有這麼多的資料，而消費面有這麼多的需求，有無落差可以從這邊作評估判斷，很多是推估，但至少有這樣更多的資料來support決策進行。

（簡報第8頁）「項次2」是「供應缺口評估及高架持續期推估」，通常產跟銷有兩種情境，一個是太多、一個是不夠，因此第一個是供應缺口，也就是不夠的部分，因量不夠，所以價格會高，因此要持續推估。這個部分已經做完資料面的分析，關貿的進口資料已經有先給我們樣本了，但是實際每一天的資料還沒有介接完成，因此資料面已分析完成，介面的部分還沒有進行設計，因此看到的還是3月3日出行的情境（簡報第13頁）。

（簡報第8頁）「項次3」是「超供數量評估及低價持續期推估」，如簡報第14頁，我們會作參數的調整，也就是全國量的部分，我們會做調整。

為什麼這邊的重要產品是兩個，但是第一張圖是十個？

通常都會有十個，至少會有十個。

（簡報第15頁）滾動倉貯釋出量的這個部分，資料面分析完了，介面開始要進去設計了，所以產生出來的還是一個雛型的畫面，這邊比較單純，也就是哪一天釋出多少、剩下的量多少，比起前面高價、低價推估的很多資料，這邊算是比較單純一點。

不好意思，我有一個問題。雖然滾動倉貯有所有數字，但是資料查詢的部分只會有釋出量，對嗎？

對。

「當日應入庫數量」、「當日尚可釋出量」是不是不會出現？

怕太多的資訊讓看資料的人誤解，也就是今天有釋出多少、我還有多少，其實就是牽涉到產銷調節的機制，我們認為有一點敏感，所以還是不太適合公開，也就是（公開）前一天的釋出量，這個公開出去會比較適當一點。

等一下，這張圖並不是公開的，這個是你們內部決策用的（簡報第15頁）？

對吼，如果是這樣子，我們當初好像也沒有考慮到那麼仔細，因為還有多少量，這個我們回去再跟業務單位確認一下。

兩邊一致就好了，如果最後決定這個不應該做成開放資料、也不應該做成統計圖，不然我去算圖的長度，我就有資料了（笑）。

謝謝君翰提醒，我們有時從資訊面去想，沒有想到業務面還有這樣的關聯在，子彈還有多少，如果把它公布出去……

如果按照你上次所說的，如果一陣子之後再公開沒有問題，不管是一天或七天或十五天，其實十五天之後，應該完全沒有敏感性才對？所以十五天前釋出多少有關係嗎？

那個沒關係，釋出多少是過了之後就ok。

庫存量是十五天前的庫存量（不公開），有意義嗎？對於外面要炒作的，這個不是反問啦！如果有意義的話，當然也許有兩個（做法）：一個是增加時間差，好比是一年前的總可以吧！另外一個是在標示上要標得比較清楚，說這個並不是當日，而是推估之類的，稍微模糊一點，這也是可以模糊的。

如果這兩個之外，還是有別的不能公開的原因，那就跟兩個市政府一樣，我們要問一下是什麼原因。

是。

謝謝。

（簡報第16頁）這個是設計原則的，有氣象的資料進來，因為以甘藍來講，全台灣都有生產，但是有主要的產區，因此請業務單位塞出來，十項作物的主要產區有哪些，因此查詢條件大概會有三個面向：第一個是時間的面向；第二個是氣象的面向，而氣象的面向是有「溫度」與「雨量」，可以用圖來查資料，也就是右邊是台灣的地圖，可以展開到某一條線，而線都會把鄉鎮的界限隔出來，因此從地圖上看，像彰化的埤頭鄉，點了埤頭鄉，埤頭鄉的氣象雨量、溫度資料都會show在這邊，時限是歷史資料，即當下已經發生的資料，虛線是未來的資料。而預估未來的溫度，氣象局有提供未來七天、雨量是未來三天，但雨量是降雨機率（資料），因此可以看到最高溫跟最低溫的預估。

雨量又分兩塊，左邊的維度是在埤頭鄉下了多少的雨量，而右邊就是降雨機率，等於是兩個維度，點了地圖之後可以出現這樣的資料。左上角的「查詢條件」也可以按照縣市鄉鎮選雨量站，因此從兩邊都可以做交叉查詢。

第三個構面是產量，甘藍的重要產區是五個或者是八個，這些資料會做像捲軸的方式，因此在地圖這邊有一個捲軸可以捲，呈現的產區可能是埤頭鄉，說不定是第二個主要的產區，往下還有第三個主要的產區，也有雨量、氣溫的資料，可以這樣捲，可以這樣捲，當然也可以跳著看，看到宜蘭的大同鄉，用地圖點拉到大同鄉，馬上就會show大同鄉的雨量跟溫度資料。

因為全省有八百多個雨量站，每個鄉鎮裡面兩、三個雨量站，但像大同鄉有三十幾個雨量站，嚇死人，但是每一個氣象站，並不是雨量跟氣溫都有，有一些可能只有蒐集雨量資料，而沒有氣溫資料，這都有可能；在這邊的話，基本上是會抓第一個鄉鎮給的氣象站資料，然後show在這邊，show出來之後，都可以作查詢。

（簡報第17頁）主要是今年度跟去年度某一個作物品項的交易量價的比對，這樣可以比較知道的是，可能今年的行政措施要釋出的這一些量有沒有反應在市場上，跟去年比起來，是不是量比較少，所以價會比較高，這在量價分析是滿常用的圖表。

（簡報第18頁）這個是進口量的部分，這個還是雛型，等公司給我們資料之後，我們會依照圖跟日及量的部分在這邊呈現。

（簡報第9頁）這個是系統運作及展現的構想，最左邊的產銷資料、資訊整合資料庫是我們把產銷相關的資料，包括Open Data的資料抓到這邊運用。

左上角的「6＋1圖表」的部分，我們會在全球資訊網讓一般的民眾接到全球資訊網，我們就會有一個資訊查詢的專區，連結進來到「6＋1圖表」。

Open的部分是透過API，是透過產銷資訊整合資料庫抓進來，這邊會有一個cache的機制，因此會在cache裡面抓一個查詢的速度，兩個入口的部分，都會署的全球資訊網裡面，點了之後可以作查詢、查閱。

（簡報第10頁）對於系統運作跟承載測試規劃的部分，測試環境會在署裡面，署裡面的系統是用虛擬主機建構，所以從CPU的核心出發，我們未來都可以作彈性調整。

這邊會有Visual Studio來作壓力測試，以剛剛的API來做，因為這個是新增加部分，我們會先針對這一個部分來作壓力測試，針對API的個別這些參數情境來作測試，基本上測試至少會三十分鐘，我們當然會每隔一段時間，會把人數增加上去，至少加到一千人，平均反應時間於三秒以下，這是個別單一API的測試，以使用者的角度來看，應該會整合複合式的查詢，這部分也會再模擬一些條件之後，來做比較整體的測試。

對於CDN評估的部分，CDN是利用網路上其他適合的這一些效能，把這一些點分散出去。我們這邊是在想說，如果要做這樣服務展現的部分，有幾個要考量：第一，有誰可能來查我們產銷的資訊？目標族群是誰？是國內或者是國外？國內應該是佔絕大多數，因此如果用CDN機制的話，到底服務提供的方式怎麼樣？在全世界的server及在台灣分布如何？如果我的使用者大部分是國內的話，也希望國內的CDN分布數多，這樣效益才會展現。因此搜尋了一下，可能像「CDN.net」是世界滿大的cdn提供者，可能還有別家，不過這邊還沒有蒐集到；世界很大的CDN提供者，其實在台灣的人很少，若一個或是兩個就不錯了。

以國內來看的話，中華電信有提供CDN服務，他們還要收費，因此我們對這一塊的想法是：我們先來看實務的需求怎麼樣，平常Access的效能分析來看看，反正我的運作環境在VM裡面，這當中隨時調整，蒐集一段時間，看看這樣的資源是否足夠提供服務；如果不夠的話，我們再來考量到底是用中華電信的CDN或者是其他的方式，也就是要分析這個需求是國內或者是國外，因此再依需求來做比較彈性的調整運作機制。

你們現在布署的虛擬主機有流量上的額外收費嗎？如果突然之間變得非常多人？

不會，因為提供專線就是這一些。

其實唯一我們擔心的是塞車問題，而不是別的，如果在本機那邊有快取起來，其實不會用到CPU的運算量，你剛剛也澄清了，流量是不會付錢，唯一的差別是那一條專線的可用頻寬而已。

如果要確立這一個情況，負載測試可不可以先不設上限？因為到一千人的時候，絕對不會用完，對不對？

嗯。

所以要知道頻寬或者是CPU先用完，最簡單的方式是測到壞掉為止，這樣一下子就知道你們目前上限在哪裡，而這個上限，我們直接跟院長或者是其他朋友說一下，他們就可以瞭解今年還不會到那麼多人，之後再想CDN；或許如果測出來的狀況很好，以至於發現真的不行的時候，再專線加速或升頻寬就好了，這樣就不一定要用到CDN。

反過來講，如果專線頻寬用完之前，機器就當掉了，快取或者是網頁伺服器還需要調整，這樣就很需要CDN，除非把這邊調好，我們就實際不設上限測測看。

大概就這樣。

不知道有什麼想法？

我有一個建議，您的報告裡面有一個資料開放所需API預估與辦理情形，像批發市場的交易量，我們的Open Data的部分，在農委會已開放完成，因此這一個下來……

……喔！那個是這樣子，批發市場的Open Data，在會裡面已經有一個，但是農糧署有一個菜價的供查詢平台，還是需要抓資料，供菜價平台的資料展現。

要做一個格式的轉換，本來類似試算表，之後會轉成JSON或者是其他的格式，並不是技術上很困難的問題，也就是資料在那邊，而是要作一個規劃的動作，並不是整批全部的試算表資料都給使用者，而是用一小部分，只是做這樣的規劃？

對。

會不會在資訊中心產出Open Data的背後，有提供API模式的情況？也就是直接接那一台server的API？

可以直接接，可以挑選市場、時間區間及作物，都可以調整的。

你要的格式給他們，他們可以生得出來。

Open Data的來源還是從農糧署來的，蒐集各地的批發市場到農糧署，提供給農委會的Open Data。其實在這一個server裡面，本來還沒有Open、做「6＋1」之前，這一些本來都在資料庫裡面了，只是未來要做Open的功能查詢，還要多弄一個API去做，因為資料放在這邊，要給不同的用，一定有一個API去把它抓回來，而這個API不難，只是SQL下一下而已。只是把它量化，所以我覺得功能應該不大。

因為你寫要五個API，但是國內產量的部分，因為事實上我們做Open Data的時候，其實API都已經開發好了，所以我個人應該可以直接。

應該是說，這邊的API永遠是這個Data的子集，並不會你們這邊（農委會）還要從頭開發Data，是不可能的。

對，我的意思是這樣子。

既然提到這一個，這二十七項是否可以作為一個類似目錄的東西？在網頁上，現在有在一個網站當中可以看的，而用樹狀列表的方式呈現出來，在資訊界是用「APIs.json」的目錄格式，至少來這個網站的人會運用的話，就知道這一個網站上的資料都是這二十七個端點組合而成，如果覺得可以畫成更漂亮的圖，像3D或者是什麼，只要回去用這二十七個端點就好。

以前都是用word或者是pdf的檔，放在網站的某一個角落，當實際程式改變的時候，這不一定會跟著更新，現在的想法是，如果現在開始設計的時候，把這個跟目錄加進去，然後跟開發放在一起的時候，大家是否比較知道二十七個端點是做什麼的；不然我現在看批發市場，沒有辦法腦補出那有什麼不同，因此有一個目錄，我相信會很有幫助。

國發會資管處也正在做這一個目錄後面文件格式的中文化，也就是OAS 3，這並不是馬上立刻就要做，但是上線的時候，有這一個目錄讓大家這一個呈現並不是唯一的呈現方式，大家可以拿去作其他的綜合運用，如果有目錄的話，可能會比較好。

我再補充一下，因為「菜價公開資訊查詢平台」基本上用Google chart去畫，因此對於查詢的使用者而言，所以介面還算容易懂，下條件，就查出來。

Google chart應該也可以下載，chart的背後資料，應該還是可以下載回去作一些運用，因此這一邊提供的並不是只有圖而已，其實還有資料可以下載回去。

我知道，因為很多人自己想說下載回去用top load或者是r分析之類的，就是儘量讓他們做這一件事的時候，比較容易一點。

打斷一下，資拓工程師可以現場show一下demo嗎？

可以啊！應該可以。

「重要產區氣象資料」，其實一開始是空的，也就是下面沒有東西，這個是「6＋1圖表」當中的其中一個，好比像3月1日開始，我們查甘藍，右邊會標記所有甘藍的產區，左邊是3月1日至4月9日各個產區的第一個測站標記出來，也就是把資料放出來；我現在透過遠端的桌面進去，因此畫面並不是很漂亮。

右邊是地圖，好比甘藍就知道事實上重要產區如紅色框起來的地方，有文查圖、圖查文的方式，現在放的是麥寮鄉，現在放的是大城鄉，另外要標記測站，有一些是很多個測站，這個沒有新竹……看一下大同鄉有很多測站。

但是中央氣象局的測站是記雨量比較多，有的沒有記溫度，像這個是只有鄉鎮的預測溫度，像太平山這一個會比較好一點，既有記溫度、也有記雨量。

各位可以看到藍色這一條線是過去三年同時期的均高溫、另外一條線是過去三年同時期的均低溫、紅色線是今年的高溫、綠色線是今年的低溫，及虛線是未來三天的鄉鎮高低溫。這個是溫度的部分，下面是雨量的部分。

請問哪裡有綠色？

不好意思，太緊張了。這個是「6＋1」圖，並不是Open Data。

我查到這一個情況，現在除了截圖之外，有沒有辦法有一個網址分析出去？

目前沒有，看要怎麼設計。

以前自己外面在幫教育部做字典的時候，查到的狀態會直接反應到網址上，後來教育部改版之後，有把我們這一個訴求納入，但是說不能直接改網址，而是變成按分享，然後就可以copy一個網址，（點選）那一個網址回來的時候，還是會跑到同一個畫面，只是包含區間跟這一些東西都會出來，但上面的網址沒有辦法直接複製，我相信這樣也ok；重點是好不容易查好了，一般來講會想要分享出去，不管是用email或者是什麼方式。

版面上不一定要用五、六個分享的按鈕，那個過兩個月就退流行，所以最簡單的方法是，看是不是按某個鍵或不按鍵，就可以取得可分享的網址，這樣是不是比較容易讓這個系統大家熟知。

重要產區氣象資料的部分，會依照作物，比如像甘藍有重要的十五個產區，用scroll bar調，十五個產區就會出現，單位是鄉鎮，像這一個是雲林的西螺鎮。

剛剛呈現的是，可以透過圖查文、文查圖的方式去點。

其實應該是置中，只是因為螢幕的關係，有scroll bar，因此會置中。

我有一個問題，聽到剛剛一點混淆，也就是「6＋1圖表」有沒有公開給一般民眾？

將來會。

當倉貯的問題解決之後，我們可以知道是「6＋1圖表」或者是「5＋1圖表」，是這樣嗎？

對。「6＋1圖表」的部分，這一些圖基本上會掛在全球資訊網那邊，也就是當作入口進去。

上次討論也是這樣子。

只是談到庫存的資訊要不要公開，或者是有時間差或者是用什麼方式公開，因此是會公開。

我再問一個問題，像網址的參數有一個user，是要使用者登入的意思嗎？

現在是，未來會嵌到農糧署的全球資訊網。

我回答一下，公開資訊目前API的設計只有針對雨量的部分，而溫度的部分也要公開嗎？

你有不公開的理由，我就沒有一定要公開。

大概是要多寫一支API（笑）。

為什麼會有這一個問題？

菜價公開平台那邊，目前只coding了……

有人會說什麼要公開、什麼不公開，而不是所有的東西都可以公開，並不是我去判斷的。

那時請教您的是，雨量對於蔬菜的影響是比較大的，台灣的氣候不會差異太大。

這邊應該是兩塊，中央氣象局的資料，在「6＋1圖表」，剛剛show裡面會有溫度跟雨量，雨量、溫度可透過全球資訊網，都可以看得到。

另外一個是菜價資訊平台的這邊，剛剛資拓問的是這邊的溫度是不是要讓民眾可以選，我們當初談的時候是想說比較會有影響的是雨量，溫度的影響比較小，除非是寒流來，因此溫度的部分，我們現在沒有把它放上去。

你說寒害來的時候，如果要分析，就從氣象局接資料，不要從這邊拿的意思嗎？

嗯……

是就是啊（笑）！

這樣大概不好處理。我們想要在這邊公開資料是覺得比較好分析、比較有用的，所以放上去，讓它去查。

可以啊！這個講清楚就好了，未來系統上線，為什麼溫度不在裡面，雖然氣象局有提供這個資料，大家分析的時候要往別的地方拿，逐字稿就可以解釋這一件事，這是ok的，沒問題。

為什麼看到這一頁的時候，還是用Google chart，你們還是要用嗎？

這不是我做的，他會評估，因為他是前端，而我是資料呈現。

其實現在是用web service，未來轉JSON其實還滿快的，一個參數而已，（展示網頁）這是API，我一直在想說這一個API未來到底要不要公開，按照投影片的設計，這個API只有對Open出來的前端，就是你們剛剛看到Google chart的畫面存取，現在為了方便互相溝通，目前都打開，可以直接下參數或幹麻，如果未來公開的話，我不會讓外面直接存取，可以丟JSON，以及看要丟什麼東西出來，如果只要抓raw data的JSON話，就可以公開出去。

是啊！如果可以攤平的話……

拿到下面web service的話，事實上就已經拿到所有的描述了。

是啊！就兩個做法，一個是現在的web service，本來就已經有工具，從這個已經產出我剛剛所講的索引跟OAS 3，這個是現成、也不用額外再寫。

外面的人想要用的時候，就會一直回伺服器拿資料，這邊撐得住，大家什麼事都不用做（笑）；如果你覺得會撐不住，一個是在中間放一個快取的代理伺服器，第一次拿了之後，在近端存取下來，在這邊改API或者是什麼樣，就不用管代理伺服器，只要管地址，本來叫V1、未來叫V2，這個是標準的做法。

另外一個做法，如果預期的量是非常大，以至於一定要用CDN，那這樣就攤平，變成一堆的「.json」檔。

我覺得兩個方案，後面比較廢工，我沒有說一定要這樣做，前面基本上只要做一個能夠快取的代理伺服器，其實基本什麼都不用寫，而是提供一個索引就好了。

因此我覺得既然這一個API都是取得的，並不需要再作額外太多的設計，一切以你們開發的沉默成本最小為原則。

目前做好的是有這幾個（demo），這個是「產量與消費推估分析」，我選品項為「甘藍」，其實是可以複選的，我另外選「結球白菜」。

可以看到甘藍的部分，黑色的部分是剛剛科長所提的，因為這個值並不是代表全國，會再乘上比率，而變成全國的預估值出來。現在看起來有一點落差，像黑色的部分跟農糧情的產銷推估會有差的，這邊調整好之後就會比較一致。

可以看到前三年批發市場的每荀交易量（黑色部分），黃色的部分是台北一、二市交易量，因為台北一、二市的交易量具代表性，因此可以看趨勢。可以再看到柱狀的部分，這是農糧署針對甘藍的產量推估。綠色虛線的部分是大宗蔬菜供應量的預測，其實會針對甘藍跟結球白菜來作供應鏈的產量推估。

像甘藍的疫苗經過四個月之後，那就是一個產出，我們透過這個方式就會計算出來，也就是呈現在虛線的部分，到時會在市場預計流通的產量，紅色的部分是台北一、二市的均價，也就是消費推估分析。

不好意思，我問一下，所以結球白菜是在下面嗎？

對。

下面這一個表是除了圖的顯示之外，還有一個比較重要的產量推估，用數值跟方式，也就是上、中、下旬的部分來作呈現。剛剛有提到結球白菜。

接著是「超供數量評估及低價持續期推估」，生產預測跟大宗樹栽（供苗）預測，還有加上前三年全部批發市場平均每荀交易量，也就是供應鏈多的，價格就會往下掉，從這邊來作分析。

這部分只有甘藍跟結球白菜，大宗蔬菜推估的話，只針對這兩種留資料而已，因此這沒有十項，剛剛君翰有提到為何沒有是十項，只有針對兩項，因此大宗蔬菜只有針對甘藍、結球白菜的資料。

所以未來也不會有其他的資料？

不會，主要就是這兩項。

目前從大宗蔬菜過來的資料，也只有這兩項而已。

所以如果民眾上來查這一個網頁的話，只能查到兩種蔬菜？

民眾沒有到這一個網址。

將來會公開，除了滾動倉貯做好之後，才有可能……

現在很多網頁，哪一個是要給民眾看的？或者是所有都是？

現在看的都會。

我們會給民眾的是這個部分，然後到一個網站。

不會連到這邊，而是會嵌到全球資訊網，一樣是有選單，但跳過產銷平台。

如果「5＋1」也要給民眾的話，應該要透過web API，有cache處理，直接對DB一定會垮掉嗎？

你們是對ASP.NET線嗎？

對。

在伺服器那邊，直接把那個page設成「可快取」，你們用自己的硬碟去做快取，不然就是中間要有一個快取的伺服器，不管是在使用端或是你們那一端，還是要有一個，不能每一筆都回到裡面去。

好。

接著這個是「主要批發市場交易行情」，而這裡會有四個重要的作物，會有上一年每旬交易量，紅色的部分是交易量、綠色是上一年同期價格、紅線是當時的價格。這只針對台北一、二市行情價格以交易量的呈現。

目前開放的是這五個，「菜價公開資訊整合平台」持續開發，至於要用什麼chart有考量到你的chart，因為我們本身就有chart在做，包含了這一些相關的功能（右上角），我問過工程師，做法都ok，沒有問題。以上展示。

我只是想要回應一下每一個動作有一個單一網址的這一件事，其實應該對你們這邊會有一些作業上的成本。

如果先不講成本這一件事，而是以單一網址這一件事來看，如果只有對相關所屬單位的話，如果有單一網址，或者我們講一件事，我跟你說不是用什麼條件去查，以這兩個動作去看的話，大概可以推估會進到這個查詢系統，一種是媒體在講這一件事，並用了這一個網址的話，人流就會從那邊進去。

第二，一些網路上比較有聲音的人，他們會列出這幾個網址，也就是用這個查，不少人會從這邊進去。

第三，像立委或者是民意代表，他們也會從這邊進去。

第四，像官方自己發出來的新聞稿，如果有相關的網址，也會從這邊進去。

因此大概會有這四個，最明顯造成人進去最多的原因。如果沒有單一網址的情況下，也就是沒有設定好的條件之下，會有很多人進去在裡面流動，一種是會按照訴說的人或者是訴說的媒體去點，另外一個是不知道怎麼操作，或還在摸索。

這個所造成的是這整個設備或系統的負擔，若我們已經設定好單一網址進去，其實會差滿多的。

如果我們在解釋上已經設定好的話，比較不會誤解署裡面有說有這一個資料出來了，我們想說在這一個條件之下的解釋是什麼，他們進去是亂點或者是點錯，因此就會是署或會裡面所說東西整個被扭曲掉，整個不太好。

要嘛就直接用javascript直接去改網址列，如果覺得這樣比較困難的話，至少有一個產生內嵌或固定網址的按鈕，就是有一個專門給人複製用的網址列可以複製。

如果兩個都沒有的話，就像彥佑講的一樣，就會自己截圖、附一句話，但是附得一句話詮釋不當，讀者沒有辦法自己檢證，這樣會造成非常多謠言。

謝謝提供這樣的網址給我們。

還有什麼別的想法？

請科長考慮一下，我前年不在國內，去年的時候回來發現水果跟菜都變很貴，因為年初都下了一場雪，足見溫度跟菜價仍有一定程度的關聯性，對我們來講，其實介接雨量，而不去介接溫度的話，基本上我覺得有一點可惜，這只是多一個動作的程序，我建議把溫度也放進來。

OK。

看大家有沒有什麼想法，如果沒有的話，我們就先這樣子。

我們有幾個確定的事項，包含跟地方及滾動式倉貯最後釋出，或不要釋出，或有時間差釋出，及這個系統繼續精進，包含網址及最後呈現時的流量測試，這部分都麻煩繼續關心，謝謝。

是不是還是以4月底作為期限的話？要不要再做一次最後確認？

上線前有沒有要做最後一次確認？或者是你告訴我們上線時間，我們就自己連過去看，也是可以，不一定大家都來開會。

現在的狀況是，這一個網址，我們其實從外面是連不上的，也不知道做到哪裡，因此才需要這樣開會，如果你們需要一個外面連得上的測試機，其實也可以書面處理，只是看大概什麼時候可以出這樣的測試狀態。

我看一下，（拿手機確認）4月底要做。

5月就是汛期了。

4月25日，資拓這邊有辦法嗎？有可能還沒有那麼完善。

沒有關係。

但是比如要提供「6＋1圖表」或者是open。

做到什麼就什麼時候，我們要解決的是從外面可以連進來，也就是測到幾人之內是不會當掉，你們要做這一件事，包含介面優化或者是用什麼畫圖，其實都可以一直改善，只是那個時候是要有資料，而不是長得很漂亮，如果汛期才上的話，公信力馬上打折扣——最基本的是，承載的負載量及從外面連得到的這兩件事，看什麼時候可以讓我們從外面測。

我們基本上是以25日為努力要達成的目標。

謝謝。有困難都可以說（笑）？

我們的困難是在資料取得，如果資料取得，其實速度滿快的。

如果資料有缺，其實就是一張圖片變成四張或者是三張，你們的表格裡面，有些是已完成，應該是可以公開的吧！對不對？

嗯。

所以最壞的情況是，上面寫「已完成」我們才看得到，「未完成」看不到，而自由點選那邊不能點，最壞的狀況是這樣；即使是這樣，25日還是可以分享的。

因為一開始期待不要設那麼高，未來會越來越好，過了兩、三天又發現多一張圖。

偷偷放上去。

因為只有我們知道上幾張圖，從外面來看是一開始自兩張到五張，這樣也不錯（笑）。

會議結束，謝謝大家。