資料英雄計畫

Fellows：林庭蔚、林瑜軒、曾俊維、陳沛瑜、呂寧遠、鍾幸芸、羅町光
Mentor：莊友欣、謝宗震
Project Manager：許瑋
Project Partner：財團法人漢慈公益基金會
社會變遷及家庭結構的改變，隔代、單親、外籍配偶及近貧等經濟弱勢家庭有逐年增加的趨勢。處於這種資源相對弱勢的家庭中，不僅課業無人指導，甚至下課後連晚餐也沒有著落。弱勢兒童及少年在成長過程中比一般家庭孩子要面臨較多貧窮風險。同時，主要照顧者因為本身照顧能力薄弱或多重角色負荷，甚難獨立承擔育兒及教養之壓力。
有鑑於家庭是個人發展重要關鍵，2008歲末，正逢金融海嘯席捲，原本就處於社會邊緣的經濟弱勢族群，影響更是首當其衝，許多家庭面臨失業、貧困的困境。在新竹科學園區的漢民科技公司，秉持扶助弱勢的使命，在風雨飄搖的2009年，成立財團法人漢慈公益基金會 ，結合當地清華大學、交通大學、新竹科學園區優勢的社會人文資源，無償為弱勢服務，提供「高關懷家庭支持服務」、「弱勢兒少生活陪讀」，免費提供課業輔導、品格教育、家庭關懷服務，藉由優勢觀點「與其給他魚吃，不如教他釣魚」自立理念，提升家庭復原力及韌性，進而恢復家庭功能。
建置高風險家庭的預測模型
在漢慈想要建置高風險家庭預測模型背後的想法，因爲在漢慈所輔導的家庭相對於一般政府機構更加的複雜和難處理，且漢慈在個案的輔導和幫助上是非常細膩的，從財務、法律支持、孩童教育上著手，往往需要課輔老師、社工、志工等一同完成，也因此有各式各樣紙本紀錄的資料。因此社工們在繁忙的情況下，往往還需要花很大心力去爬梳個案資料，得出一個全貌，尤其是對於初接案的社工，或是新手基金會夥伴，使得經驗不易傳承。
總結圍繞漢慈想要建置高風險家庭預測模型的相關問題：

如何使用這些記錄幫助漢慈裡的夥伴能更快速簡單掌握一個家庭的全貌，減少花費在翻閱紙本紀錄，且能由幾年來累積的資料萃取出一些經驗呢？

能否梳理漢慈夥伴們過去幾年的心血，設計一套高風險家庭的預警系統呢？

如何幫助社工們更方便的存取紀錄資料，以利往後進行資料分析，發揮資料的價值呢？

解決方案
專案開始是以建置高風險家庭的預測模型為出發，經過跟漢慈的夥伴討論後，評估三個月的工作時間和收集相關圍繞漢慈細節的問題，我們提出的解決方案包含一系列可以做的事情和優先順序。

整理漢慈內部所擁有的資料
挑選可以用來作為高風險家庭預測模型的資料
嘗試可能的分析方式來預測相關高風險家庭
將整個分析方案建置成完整的應用

資料描述
漢慈這邊提供的資料，主要有下面幾類：

個案的開案資料，共有78個個案
個案的家訪資料，共有46個個案
高風險家庭的風險因子對照表，共有7大類風險因子，分別代表家庭功能的各個面向

經濟功能：46個細項指標
教育功能：40個細項指標

Fellows：劉憲錡、林立哲、郭冠伶
Mentor：謝宗震
Project Manager：莊靜雅
Project Partner：高雄市政府消防局

Introduction
高雄市消防局自成立以來，咸奉「預防火災」、「搶救災害」、「緊急救護」之消防三大任務及其他為民服務事項，共同努力。為達成積極主動為民服務之使命，消防員24小時受理民眾需求並隨時出勤執行各項救災救護任務。每次的出勤任務都代表著人民傷亡或財物損失，同時也耗費國家的人力資源，卻無法徹底解決問題，因此預防火災便成了消防局積極推動的首要目標。
Problems
有鑑於住宅火災佔總案件數一半以上，高雄市消防局加強宣導住宅社區火災預防措施。但如何善用有限人力與資源，進而顯著降低火災發生頻率，一直讓消防局苦無對策。於是消防局與資料英雄合作，冀望能從建築物角度出發，彙整住戶與周遭環境資料以建構出建物火災風險預測模型，進而找出高風險住宅戶做居家訪視與社區消防觀念宣導，此外，本專案交叉分析不同數據，希望從中闡述新穎觀點以作為決策參考。
Method
資料處理
為評估建物火災機率，建築物火災風險地圖是以建物門牌號作為每一筆資料的索引，在高雄市政府機關大力的配合下，取得自稅捐處取得十三萬餘筆左營區地價資料、地政局建照十三萬餘筆建照資料。透過 Python 與 SQLite 反覆比對地址以及對地址進行正規化處理後，我們合併出約八萬九千筆資料。另外，根據金門大學火災預測碩士論文（link），承蒙社會局提供左營區身障、低收、獨居老人資料，加上消防局的狹小巷弄、火災報案紀錄，我們整理出以下特徵值。

資料處理實際上是這次專案花掉最多時間的地方，因各處室資料格式繁紊不一，資料整併窒礙難成。冀望將來，市府能將跨處室之集中資料倉儲作為資訊基礎建設之基石。

平衡學習 & 非平衡學習
在訓練建物火災機率模型初期，我們嘗試以深度學習演算法建置模型。我們得到 99.9% 的準確度，而後發現模型預測所有的建物都不會失火，因訓練資料中未失火的建物佔絕大多數，僅約四百筆建物曾失火，模型無法學習到失火建物的特徵，故模型猜測沒失火，且可藉此得到高準確度。
建物火災機率預測實為典型的非平衡學習，而準確度之於非平衡學習不是個好的指標。我們發現我們的初期模型在召回率方面的表現非常差。參考過往文獻後，我們決定以 BalanceCascade 的方法來訓練模型。下面我們將一步步介紹如何實作 Blanace Cascade 方法。
首先，我們需要對所有未失火的建物進行分群。我們將建物分成 137 群，每一群擁有八百筆建物資料。為此，我們採用了kNN（k-Nearest Neighbors）演算法。

為期四個月的資料英雄計畫，一群來自不同背景的資料夥伴被集結。從程式開發、統計分析、資料探勘到系統開發不同的技能，有人是醫學系學生，有人是消防隊緊急救護員志工、還有醫院急診部的醫師。「透過資料力，讓急診救護達到正向的循環」，這樣共同的想法將我們聚在一起。與提案方高雄市衛生局進行合作，引入資料科學的方法論，對高雄地區的歷年救護資料進行分析，為緊急救護與醫療界盡一份力。
OHCA（Out-of-Hospital Cardiac Arrest ，到院前心肺休止）是指病患在送達醫院的急診室前出現心肺功能停止之情況。當心跳停止達四分鐘時，腦部將會因為缺氧而受損；當超過十分後，腦部就可能達到永久損害而成植物人。因此，OHCA 病患的分分秒秒都在與時間拔河，在急重症檢傷分類中視為最優先處理的案例。
搶救黃金時間，不能只靠一己之力，必須仰賴上、中、下游的資源整合。「生命之鏈（Chains of Survival）」從社區、消防端、急診端及照護端整合眾人之力，透過五個環環相扣的流程，提高急救復甦及癒後健康的機會。
(https://i.imgur.com/rGYnl0T.png)
根據「熱區辨識」、「危險因子分析」、「緊急醫療優化」三個角度，定義了下列三個具體的問題，並預期從資料中解析出改善之道：

了解 OHCA 發生風險及其因素
了解 旁觀者 CPR 介入情況與效益
了解 社區救護資源分配優先順序

資料旅程 Data Journey
採用的資料集主要分為兩份資料：

OHCA 救護資料集 : 2010-2016 的 OHCA 消防端+醫院端資料
外部資料集 : 空氣/溫度/人口公開資料

我們針對了「OHCA 救護資料集」當中重要的

Fellows：王郁秀、王景弘、陳雅韵、潘柏任、謝依珊、李曜容、柯景泰
Mentor：謝宗震、劉嘉凱
Project Manager：張盈宜
Project Partner：台北市家庭暴力暨性侵害防治中心

本專案與臺北市家庭暴力暨性侵害防治中心（簡稱家防中心）合作，以家庭暴力案件預警與風險管理為目標，希望達到「降低被害人再受暴風險」及「提高社工服務效能」兩個主要目的。
我們以現有資料發現能夠從「區域」及「個案」兩觀點切入問題。透過區域資料建立家暴案件特徵地圖，能夠達到社區預防作用，減少盲目的宣導政策，另外以個案特徵（因案件種類及資料完整度，我們僅限縮在親密關係暴力），嘗試建立預測模型，此模型能作為預警系統，新進個案若呈現高再受暴特徵，則社工能早期預防，防止多次家暴發生，避免受害者身心狀況惡化以及過多的人力資源投入。

以下我們將分別描述此兩觀點的詳細作業流程。
[地圖組]

以「區域」觀點探索家暴案件
「村(里)」為中華民國之第四級行政區劃名稱；亦是最基層之地方自治單位，因此多數政府單位資料上的建置皆是以此做劃分，家防中心的資料亦有此特性。故我們針對家庭暴力案件建置以「地點 (村里)」為主體的通報熱點警示指標，透過有效評估工具篩選個案件類型之高危機區域，希望能減少與里長溝通的資訊不對稱，共同推動社區意識防護家暴發生，加上外部單位如：學校、醫院、警察等通力合作責任也是依據區域分工，此時家暴區里風險地圖正式成為相互共通語言，大家需要共同知道處理問題之資源分配的優次緩急，才能一齊有效率的解決台北市家暴問題，進而將此機制推廣至全台灣，讓台灣最美的風景依然是人。

方法 (Methods)

Google 地圖API

讓填答地址先轉經緯度
再以經緯度判斷轉成里
判斷失敗的地址以人眼辨識修正

資料清理ETL

移除重複CA夾
去除非台北市的案件
去除沒有地址者
計算欄位：各區、里by案種的男女比重、年齡比重，及總家暴案件數、案種排名百分比、低收或者障礙排名百分比

Fellows：曾凱聲、張凱鈞、宋培源、王宜婷、許筱翎、韓鈺瑩
Mentor：謝宗震、劉嘉凱
Project Manager：王蕙盈
Project Partner：高雄市政府消防局

對抗火災的最佳策略是採取預防性攻擊，防患於未然。若用資料科學的語言描述，就是定義問題、資料盤點與清理、分析建模、預測、決策支援。
以高雄市為例，每年的火災案件不到一百件，但是消防隊員還是忙不完。有一個重要的原因是，雖然每年「火災」數量不多，但是「火警」的案件卻是數以千計。火警和火災，差別只在一線間。家中瓦斯爐燒開水未關，鄰居報案後，消防隊來得及破門而入關掉瓦斯，就只是火警；來不及關掉，就可能演變為造成生命與財物損失的火災了。而不論火災或火警，其危險因子（例如起火原因、建築物特性、人口特徵等等）可能都是共通的，若能評估火警風險，或許就等同建立了火災風險模型。這即是 D4SG 資料英雄計畫「火災風險地圖」專案正在設法解決的公共問題。
我們是一群「用資料力做公益」的資料英雄，很榮幸與高雄市政府消防局合作，利用週末和晚上，共同分析過去數年的消防案件，從無到有，開始打造台灣第一個「資料科學，打火救人」的實戰經驗。
高雄，加油！
資料來源

1. 高雄市政府消防局火災紀錄資料
2. 高雄市政府消防局火災分析表
3. 高雄市政府消防局火警出動人車數
4. 高雄市政府消防局各大隊補助安裝住宅用火災警報器場所清冊
5. 高雄市政府社會局資料(低收入戶、獨居長者、身心障礙)
6. 高雄市政府稅捐處建築物資料
問題解決

一、人力配置
問題
如何使人員排班更有效率？（每個分隊在什麼時段可精簡人力，什麼時段須要多加派人力？）
高雄市政府消防局每個隊員的值班待命時間為早上8點到隔天9點，共25小時。
若能從歷年的火災紀錄看出忙碌的時段差異，在較不忙碌的時段安排較少的人力，在滿足基本戰力與鄰近分隊即時支援的前提下，不必讓每個隊員皆值勤25小時的時間，能夠讓隊員有更多時間休息，避免不必要的人為疏失，並作更有效率之人力配置。
分析
1. 以派遣次數的角度出發：
分隊的派遣次數越多代表該時段火災火警發生越頻繁，消防人員出動的次數越多。以線圖呈現分隊忙碌的時段。使用分析欄位：案件時間、派遣分隊、案件狀態。

Fellows：陳晉暉、陳均豪、林家慶、周立筠、吳彥霖、楊承翰
Mentor：謝宗震、劉嘉凱
Project Manager：鄧凱元
Project Partner：天下雜誌、國家太空中心

農電組製作了一個網頁陳述完整專案報告 (https://d4sg-solar.github.io/)
 
以下整理天下雜誌呂國禎副總主筆在10/26成果發表會的報告內容
問題定義
農地種電的利益與衝突
電業法將台灣電力結構入法，50％天然氣、30％燃煤、20％綠電成為法律規定。太陽能光電目標20GW(核四*7)，目前總裝置容量0.95GW，未來將種20倍的太陽能
種那裡？ 農地上，那台灣有多少農地？
農委會統計的台灣農地約81萬公頃，主計處調查台灣農地(含特定農業區、一般農業區)實際耕種剩44.6萬公頃
參考資料

資料英雄計畫調查結果
國家能源政策綱領 (電業法)
行政院主計處，臺灣農地統計
農委會，嚴重地層下陷地區內不利耕作得設置綠能設施之農業用地範圍
環保數，污染農地調查工作
台電資訊揭露

分析成果

衛星照片定位雲林縣農地上的太陽能面光電板面積、數量
嚴重地層下陷地區
受污染農地
農委會農業收入調查
田野實地調查

成果發現

雲林縣太陽能光電板種電位置與污染農地並無正相關，太陽能板未種在受汙染農地上
雲林縣太陽能板種電與嚴重地層下陷地區呈現正相關，光電板集中於高鐵通過沿線鄉鎮

INTRODUCTION
視障朋友從事按摩以外的工作時，常常面臨多重挑戰，其中有視障所產生的就業困境；同時也會面對一般普遍的就業挑戰。在非營利組織 雙連視障關懷基金會，致力爭取視障朋友工作機會下，按摩小站設立於醫院，提供一個明亮開放的空間，在醫療院所明亮開放的環境下，願意嘗試視障按摩的朋友因此變多！視障朋友藉於按摩小站服務，走入社區，走入人群，讓更多人了解視障按摩、了解視障，進而創造對視障朋友更友善的社會環境。
 
PROBLEM
在非營利組織 雙連視障關懷基金會 積極爭取下，目前有10個按摩小站，大多駐點於醫療院所內，提供約100位按摩師穩定就業機會。然而累積了大量紙本的記錄工作表與非細節的電子式文檔，卻因為資料不夠完善，讓這些寶貴資料無處發揮。 另外，按摩小站的排班在管理是一大負擔，人工調動排班靠得是人腦記憶跟有限的資訊，此時就有可能造成師傅之間的誤會。所以如果在有大量可用的資料後，進而發掘資料價值，透過資料分析，產出信服人的資料視覺化呈現。

在有大量可用的資料後，進而發掘資料價值，透過資料分析，產出信服人的資料視覺化呈現。
(Image Credit: http://d4sg.org)
METHOD
根據上述所遇到的問題，我們分為兩個部份：

後台的資料庫管理要如何呈現？資料的欄位要有哪些？
前台要給使用者哪些比較的選擇？以及比較過後給予回饋的呈現？

[1] Azure架設資料庫建設前後端。後台使用 php將功能主要分為「增加工作記錄」與「管理按摩師傅與各小站」。原本 雙連視障關懷基金會 提供的電子檔資料只有儲存一個按摩師傅一天總共的薪水，與紙本上相比未將「指定節數」、「未指定節數」和「來客數」等詳細資料也作記錄。為了統一資料庫名稱，我們共同討論資料欄位名稱，這時我們就將前述也附加上去。
[2] 前台使用 JS 傳使用者選定資料跟後台要資料庫資料的時候，會依據後台接收到的字串，使用 python plotly 做資料視覺化呈現，再透過 api 方式傳回前端。
DEFINE:
asg 指定節數, nasg 未指定節數,