龍洞資料浮標 恢復觀測

氣象局

龍洞資料浮標遭受蘇迪勒颱風破壞，於2015/8/8 8:00起觀測資料中斷並損毀；

已於2015/10/27 12:00 重新布放完成恢復正常作業;目前已運作正常。

#測站維護

Delft-FEWS 應用案例 002

澳洲 墨爾本目前發展之防洪綜合決策系統系統
Melbourne Water’s Flood Integrated Decision Support System (FIDSS)
墨爾本洪水預警的系統發展最早開始於1974年
在2011年2月澳洲墨爾本大淹水後
當局開始思考原先系統的應用與發展
經過一連串的評估與討論後
在2014年決定採用Delft-FEWS作為後續系統發展的核心

在搭配澳洲氣象局應用Delft-FEWS發展全澳洲

HyFS (National hydrological modelling and forecasting system)架構下

2014年開始進行墨爾本水文氣象資料與模式整合工作
在2015年開始進行作業化預警作業流程
使得各單位的模式與資料交換作業可以更加快速
相關單位預報作業人員即使轉換不同單位也無需擔心
需要重新學習操作與適應的問題
參考網址：
http://www.floodplainconference.com/…/David%20Kirby%20Full%…

https://www.youtube.com/watch?v=V4jPbAwrsLs&feature=youtu.be

Docker DATA

Docker

Postgresql

https://hub.docker.com/_/postgres/

 

JBoss community projects with JDK

https://hub.docker.com/r/jboss/base-jdk/

 

TOMCAT

https://hub.docker.com/_/tomcat/

 

資料使用問題

資料使用問題

多年前的一場研討會上針對計畫成果內容進行簡報後
台下有位先進針對資料來源與應用上提出他的看法

確認資料來源
    確認資料正確與合理性
    確認資料使用方法合理
    確認資料輸出內容正確無誤

   

    在當時 自己認為相關作業流程都有依照這幾個概念
     在進行應該不會有問題出現

     但隨著對於相關計畫的接觸與了解後
     確實會發生 連第一個最基本的要求都無法100%有效確認資料
     來源的狀況
     
     在相關單位層層介接資料與各單位間對於
     資料管理的態度都不相同的情況下
     確實很難完整提供相關正確的資料來源
   
    例如 先前遇到相同機關內跨單位的整合上

    連最基本的測站資訊都有好幾個版本甚至出現編號衝突的狀況

    這問題還沒解決

    另外 資料也會出現 相同的測站資料來源 在不同單位的數值上會出現差異

  如圖所示看到資料的數據超過一定大小數值時 就要能評估該數據是否合理

  否則若將資料匯入後續運算流程 那就真的是 亂算一通了


 因此透過歷年的觀測數據 搭配相關經驗資料

可以設定每一個測站合理的數據範圍

以便在進行資料處理過程中可以判斷數據內容是否合理

來減少資料來源不正確的問題的影響