公告版位
我是公告
上次 g0v 黑客松,有 NGO 帶著去監察院申請出來的幾名政治人物的政治獻金的掃描檔,想問問看 g0v 能怎麼做
一共有 94 個檔案,將近 2800 頁,包含馬英九、顏清標、吳育昇、丁守中等人的政治獻金的各種收入、支出登記資料

拿到的第一件事,當然是先把 PDF 轉成圖檔傳到雲端啦~ 於是我寫了一隻程式去把 94 個 PDF 檔一頁一頁換成圖片上傳到相簿中,並且產生一個 list.csv 來記錄每個檔案的位置

完成了第一步之後,再來就是要做影像分析了,因為我要找的是表格中的框線,這時可以用到的是 Hough Transform (霍夫轉換),這是霍夫在 1967 年提出,用來做直線檢測的技術,而 opencv 則有提供現成的 HoughLinesP function 可以抓出一張圖片內所有線段
於是我用 C 寫了一個程式,給他一張圖片位置,他會給我這張圖片內所有線段位置的資訊的 json
於是透過 opencv 處理後,原先的圖如下:
政治獻金原圖

opencv 抓出來的線段位置
opencv 抓出的線段位置

其實已經可以看出 opencv 抓的很準了
不過opencv 抓到的一條框線中其實可能是數十條小線段聚在一起,所以我必需要把這些線段 group 在一起
於是接下來我用 PHP 寫了一個程式,其中的 addLine method 在做的事就是把輸入的線段 (x1, y1) - (x2, y2) ,透過公式 r = x * cos θ + y * sin θ 算出他的 θ 和 r ,然後把 θ 和 r 接近的 group 在一起,這樣子就可以抓出正確的框線了 (小時候學的三角函數在這時候竟然變得很重要 XD),得到了各線段之後,再用 getCrossPoints method 取得各垂直和水平線段之間的交點,這些交點資訊就是每一個欄位的四個座標點了,於是我再把這些資訊匯出到一個 output.csv 檔案(還在持續更新中..目前正用 Amazon t1.micro 機器慢慢處理中),大家就可以拿這個檔案來利用了

我也拿了這個結果做了一個陽春的 demo ,可以點進去看每一份文件的表格欄位切的如何,畫面如下:

demo

也歡迎有人接力把這個處理好的資料做成 captcha 之類的服務,讓群眾可以幫忙來把這份監察院不願意數位化開放的檔案來民間數位化吧!

Posted by 榮尼王 at 痞客邦 PIXNET 留言(16) 引用(0) 人氣()

以前我總有個疑惑,「農曆」的名稱有個農字,應該是因為農業而生,那為什麼農曆用的是月亮曆法而不是太陽曆法呢?
農業上太陽應該遠比月亮重要多了吧?
太陽的位置影響了四季的變化以及二十四節氣,而這些對農業才是最重要的
(事實上二十四節氣是陽曆的東西而不是農曆的東西)
相對起來月亮好像對漁業影響比較大

後來K了維基百科以及一些 Google 上面的說明,才解決了我的疑惑。
事實上我的疑惑本身就是錯的,農曆並不是只用月亮曆法,而是陰陽合曆,太陽月亮皆使用。
(所以把農曆稱為陰曆其實是很不準確的)

先說一下如果純粹用陽曆會遇到什麼問題
陽曆是靠太陽曆法,能觀測到的包括一年大約 365 個日夜,太陽和天上大部份星星就會跑到同一個位置(其實應該是地球跑到同一個位置)
對北半球來說
一年中會有某一天正午時間影子會是往北最長 (冬至)
一年中會有某一天正午時間影子會是往南最長 (夏至)
春天中會有一天白天跟夜晚長度一模一樣(春分)
秋天中會有一天白天跟夜晚長度一模一樣(秋分)
除此以外,似乎就無法觀測到什麼特徵了
等於是我們只能知道冬至是哪一天、夏至是哪一天,其他天可能就只能用 「今年夏至後72天」來記錄
如果跟別人約時間時說我們約在「今年春分後34天」見面,別人應該會數到瘋吧
而且像「白天跟夜晚長度一模一樣」這種東西,你不觀察一整天怎麼可能會知道..

至於現今所用的公曆的一年 365 天、大月 31 天、小月 30 天、二月 28 或 29 天,四年一閏、百年不閏、四百年又閏
這些是靠規定出來的(1582年教宗格列高利十三世頒行的格列曆),而不是靠自然現象觀察出來的
沒有透過強力的政治力去推行以及工具的輔助(印出日曆、月曆),對於一般人來說是很難使用的

相對起來使用月亮曆法就簡單多了,月亮平均 29.5 天繞地球一圈
只要挑月亮不見和月最圓的一天當做初一和十五,這樣子我看到月球今天的圓缺就大概能知道今天是在一個月中的幾號了
比起冬至到夏至中間會有 180 天以上要記簡單 12 倍! (這樣算好像怪怪的 XD)
所以我可以跟人約「這個月十七號」、「下個月初三」見面,只要透過月亮圓缺大概比較一下就不會搞錯天了

但是如果只用月亮曆法並沒辦法解決跟四季節氣相關的問題
所以農曆又訂出了結合了二十四節氣來決定月份的規則
首先以冬至所在月份一定是十一月(又名冬月)

然後再以二十四節氣中的大寒訂在十二月,雨水訂在一月,春分訂在二月,穀雨訂在三月,小滿訂在四月、夏至訂在五月、大暑訂在六月、處暑訂在七月、秋分訂在八月、霜降訂在九月、小雪訂在十月
如果正好兩個節氣直接隔到兩個月,就插一個閏月在中間,至於插在前一個月還是後一個月,由中氣來決定

上面好像很複雜吧?不過也只要由國內管曆法的人處理
對一般農民只要知道冬至是哪一天來慶團圓一下,隔壁老王說下個月要過年了表示現在是十二月,隔壁老李好像在包粽子表示快到五月初五了,牛郎織女被鵲橋連在一起了表示現在七月了
閏幾月有那麼重要嗎? 好像也沒有那麼重要
閏幾月就交給官府那些欽什麼監的人去煩惱就好了
我只要自己透過月亮就可以知道今天是幾號了

金庸小說俠客行最後面史婆婆約石破天約在三月初八如果不見就投河自盡,等石破天想到時發現已經過了一個月了以為為時已晚,但是不知道有閏二月,結果剛剛好準時到達

白萬劍道:「是啊,今日是初八。」白自在又問一句:「三月初八?」白萬劍點頭道:「是三月初八。」白自在伸手不住搔頭,道:「我們臘月初八到俠客島,在島上耽了一百多天,怎地今日仍是三月初八?」白萬劍道:「你老人家忘了,今年閏二月,有兩個二月。」

此言一出,白自在恍然大悟,抱住了石破天,道:「好小子,你怎麼不早說?哈哈,哈哈!這閏二月,當真是閏得好!」石破天問道:「什麼叫閏二月?為什麼有兩個二月?」白自在笑道:「你管他兩個二月也好,有三個二月也好,只要老婆沒死,便有一百個二月也不相乾!」眾人都放聲大笑。


也許小說中的故事在古代很常發生吧

事實上農曆的閏月也是相當複雜而且甚至各國還會不一同,像是2012年台灣和中國都閏三月,韓國卻是閏四月,造成當年兩邊的端午節差一天。不過這也不是我們需要煩惱的,以現代來說,這個給中央氣象局去煩惱吧!
(交大資工蔡神的計算機概論都會出寫格列曆的萬年曆程式,如果之後出農曆萬年曆程式的話就該要煩惱了 XD)

Posted by 榮尼王 at 痞客邦 PIXNET 留言(1) 引用(0) 人氣()

GitHub 在今年六月增加了 GeoJSON 的支援 可以直接預覽 GeoJSON
在八月則增加了 CSV 的預覽功能
以及在十月推出了 government.github.com 希望大家把各國政府資料往 GitHub 上丟
看的出來 GitHub 的野心不只是放在程式開發者身上,他也想成為資料的收集者

不過他的 GeoJSON 和 CSV 預覽功能因為是透過 JavaScript 在前端做的,因此有大小限制,超過大小就無法預覽了
只是地理資訊的部份,很多資料是很容易超過大小,為了讓 GitHub 能預覽而故意把精準度壓到很低其實也不是很好的方法
所以我做了一個工具,可以線上預覽超過 10MB 的 GeoJSON 和 CSV。
(不過超過 100MB 可能還是會失敗,畢竟 100MB 的 JSON 要 decode 有時候就會把記憶體吃光光了,這些就要額外再多做些處理)
這個工具在這邊 http://github.ronny.tw
只要進去首頁輸入你的 GitHub 檔案的位置,就可以預覽更大的 GeoJSON, TopoJSON 和 CSV ,甚至是 GeoJSON 和 CSV 的組合喔!
或者是在瀏覽 GitHub 檔案時,將網址的 https://github.com/ 改成 http://github.ronny.tw/ 也可以喔
下面來示範一下支援哪些類型吧!
, , ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

去年底第一次參加 g0v 黑客松我的作品就是選舉地圖 (2012/12/2 ,今天正好一年 XD)
把各村里投開票所藍綠的得票數配上村里界圖作出的地圖呈現
不過當初做這個有個很大的缺點,就是村里界圖是一個接近 3MB 的 GeoJSON,要 load 進瀏覽器來處理真的會耗掉很多資源
而且 3MB 已經是把精細度壓到很低了,應該是到十公尺以上的精細度了吧,原始資料是 60MB
像是 GitHub 最近有支援預覽 GeoJSON 的功能,也是在瀏覽器上直接計算,但是有 1MB 的限制,要不然真的會很慢又吃掉不少頻寬
所以最近幾個月我開始想要轉換作法,改成在 server 端作出圖片,然後疊在現有地圖的作法

新的成品就在 http://github.ronny.tw/ronnywang/sandbox/blob/master/20131126/2012-president-color.json
這邊是利用 Google Map Javascript API 的 ImageMapType ,他會把顯示出來的地圖上面,切成 256px * 256px 的 tile(大小可自行設定) ,使用者捲到哪裡,API 就自動去呼叫 getTileURL 要去畫出哪些 tile
而 getTileURL 裡面的參數 coord 就可以取出這個 tile 的左上和右下的經緯度分別是多少,所以後端伺服器只要畫出這一塊區域的圖型就行了

我目前寫出來的一個 Tile 的 PNG 依複雜度會是 1kb ~ 50kb 不等(看上面的資訊量)
圖片長的會像下面一樣


網址:d4ru4jg0u8swg.cloudfront.net/wms?Request=GetMap&Layers={"type"%3A"colormap"%2C"set_id"%3A27%2C"tab"%3A"\u85cd\u7da0\u5730\u5716"}&BBox=119.9267578125,23.32208001137843,121.025390625,24.32707654001865&Width=400&height=400

一個 Tile 就會如上,從網址看的出來是要畫出經緯度界於 (119.926E, 23.322N) 到 (121.025E, 24.327N) 之間的資訊,並輸出成 400x400 的圖檔
改用 Tile 真的也能省下不少頻寬,想想看原先 60MB 的 GeoJSON 省下來,就足以傳超過一萬張 tile 的圖片了
再加上 Tile 圖片可以過 CDN cache 起來,這樣子後端 server 就可以很閒只要畫一次就好了

而完成這功能的最主要核心有兩個,一個是透過 PostgreSQL 的 PostGIS 如何快速取得需要的經緯度之間的資訊,以及如何把這些資訊畫成 PNG 傳回來
前者我之後會再找時間寫成文章
後者的話我已經把程式 open source 在 GitHub: https://github.com/ronnywang/geojson2image
只要丟一個 GeoJSON 進去就可以輸入 PNG
唯一用到的函式庫是 PHP-GD
詳細用法我就不在這邊說明了,有興趣的人就翻 GitHub repository 內的說明吧

為了做到這件事我遇到一些問題並且解決掉
遇到的問題包括
1. 地球是圓的
我最早的作法是假如要把 (119.926E, 23.322N) 到 (121.025E, 24.327N) 之間的資訊畫到 400x400 的圖檔上去
就表示目標圖檔的 1 個 pixel 會是 (121.025-119.926)/400 和 (24.327-23.322)/400 的資訊
這作法如果只處理台灣的話沒什麼問題
但是當一處理到世界地圖時就爛掉了
(為什麼地球要是圓的啦~是平的有多好!)

原因是在不同緯度,每1經度的寬度都是不一樣的,像是赤道上的1經度是最大的,而極點上的1經度就是接近0
解決辦法就是要加上 sin, cos 來計算了
這應該是高中三角函數的程度,但是脫離學校太久我已經懶得計算這些 XD
所以直接找有沒有 code sample ,找到了一篇Bing Maps Tile System 裡面有(謝謝微軟 Q_Q)
就解決這個問題了

2. 經度是有可能 +180 跨到 -180 的
如果沒處理到這個問題的話,就會發生明明座標是 +179E => -179W 只走 2 個經度,圖卻畫成走了 358 個經度
這邊我的解決方式是先把經度都加上 180 ,讓他座標系從 -180 => 180 變成 0 => 360 比較好計算
然後如果遇到需要畫的區間經度是在 +XXX 到 -YYY 的話
我就把他分成 +XXX ~ +180 和 -180 ~ -YYY 兩張圖再組合在一起
就解決跨經度的問題了

GeoJSON2Image 這個 PHP class 寫法滿單純的,沒用到太多 PHP 的奇技淫巧,大部份都是 foreach 加上四則運算
所以也歡迎轉換成其他語言喔!

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

前幾天建了一個 GitHub repository: https://github.com/ronnywang/data.taipei.gov.tw/
裡面把一些臺北市政府資料開放平台的地理相關資料,從原先的 ShapeFile 轉換成 GeoJSON,包括 Big5 的也轉成 UTF-8 了,座標也都統一換成經緯度
列表在 https://github.com/ronnywang/data.taipei.gov.tw/blob/master/geo.csv

GitHub 因為現在有內建 GeoJSON 預覽功能,所以有一些資料就可以直接看了
像是 臺北都會區大眾捷運系統路網圖, 臺北都會區大眾捷運系統車站點位圖, 大臺北地區捷運車站出入口

完整列表可以到
http://ronnywang.github.io/data.taipei.gov.tw/index.html 查看

不過我也沒有轉換全部的資料,如果有需要的資料沒有轉換的,可以有以下選擇:
1. 自行 fork http://github.com/ronnywang/data.taipei.gov.tw/ ,更新 geo.csv (不需要填入更新時間) ,跑一遍 scripts/geo_update.php (需安裝 PHP, PHP-Curl, NodeJS) ,就會轉換好資料並且更新 geo.csv 的更新時間
記得要送 pull request 給我讓我也更新一下喔
2. 送 issue 給我,如果我有空的話也可以幫你抓一下

希望這些資料能夠讓大家更容易使用,這樣才能展現 open data 的力量!

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

其實地球上根本就不該存在 Big5 JSON 這種東西
RFC 4627 有提到: JSON text SHALL be encoded in Unicode.
所以像是 PHP 在 json_decode 時,如果遇到非 UTF-8 字元,就會直接噴 NULL 給你,並且跳出 「Malformed UTF-8 characters, possibly incorrectly encoded」,連用都不給你

但是假如很不幸的,就真的拿到了一個 Big5 JSON 怎麼辦?
例如像我現在要用 ogr2ogr 把政府 open data 的資料轉成 GeoJSON ,結果因為他的內容是 Big5 ,產生出來就是 Big5 JSON 了
直接用 iconv 轉,就死在台北市內湖區成功路了

昨天找到一個解決方法是

1. env LC_CTYPE=c sed -i 's/[\x81-\xFE]\\\)\\/\1/g' {big5_file.json}
(如果 LC_CTYPE 預設是 UTF-8 的話,就會在 \x81 這邊出現錯誤,所以改成 c 讓他可以處理任何 binary)
2. iconv -f big5 -t utf-8 {big5_file.json}

因為 Big5 的 SPEC 有說雙位元字的第一個位元會是 0x81 - 0xfe 之間 ,所以只要針對 [0x81-0xfe] 和 \\ 連在一起的替換成只有一個 \ 就行了
這樣子許功蓋都可以解決了

(都已經快 2014 年了,還要處理 Big5 問題...)

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

如果有一個台灣各鄉鎮平均家戶用電的數據,你覺得這數據會看到什麼特別的地方呢?
都會區的平均用電比較高,鄉鎮的用電比較低?
蘭嶼因為電免錢,用電量遠高於平均?

環保署幾年前推出了一個網站 「環保署綠色生活網」,主要目的是為了推廣節能減碳,因此由台電提供縣市、鄉鎮甚至到村里等級的每個月的非營業家戶用電量
(縣市和鄉鎮資料是來自帳單的郵遞區號,因此資料是相當準確的,但是村里是來自戶政司的地址轉換成村里的服務,這個就不太準確了,會有很多對應不到的)

這個網站的成立目的是為了推動各縣市的節能運動,因此也有一個各縣市的省電比賽,不過 2010 ~ 2011 年出來的省電比賽很有趣 XD
http://ecolife.epa.gov.tw/Cooler/statistics/map_Electricity.aspx

top5
第一名「連江縣」,第二名「從缺」 XD
根本沒有省到任何電嘛

不過他沒有顯示 2011 ~ 2012 的比賽,到 2012 年又正好相反了,除了連江縣和金門縣電力成長以外,其他縣市都減少了 XD ,主因應該是 2012/5 第一次油電雙漲造成的吧,所以調漲電價的確是省電最大的誘因。

我把村里鄉鎮的電力資料全部挖出來放到 Github,歡迎大家可以抓下來做些分析,我原先也有把 2013/3 的資料,配合主計處那邊的村里家戶數資料,算出家戶平均用電量,放在 avg.201303.csv ,不過很奇怪的是很多鄉鎮的資料很怪,像是石碇石門一戶只有平均2度電,這也太低了吧? 昨天 @MuYueh 找到原因了,因為台灣電費是兩個月收一次,所以才會很多鄉鎮每隔一個月電量就會超低,所以如果要顯示正常的數字的話,應該要以兩個月為單位,於是我生出了一個 2013/6-7 的資料 ,總算是看起來比較合理了。

我也把這個資料做成地圖化

map
線上看

有興趣可以拉近看看各鄉鎮的顏色喔。

比較之後發現的確蘭嶼的家戶用電量是台東縣最高的,但是跟其他縣市比起來,蘭嶼用電量並沒有特別高,所以請不要再用蘭嶼人整天開冷氣不關來批評蘭嶼人反對低階核廢料放置在蘭嶼了,他們並沒有比其他縣市的鄉鎮用更多電。

大家也可以來看看能從這些數據中觀察到什麼現象吧,看看你在你家的鄉鎮中用電是在平均之上還是平均之下吧!
, ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()


台北建築年齡截圖
 
感謝 Lookinfo 看資訊幫忙截圖 XD

昨天我用之前的資料做了一張 Taipei, Taiwan: The age of the City 的地圖,下面來分享一下製作的過程




晚上正準備看完 Twitter 再關燈睡覺時,突然看到跟我有關的關鍵字



因為我在今年有爬出台北市建築使用執照的資料放在 http://tpebuilding.g0v.ronny.tw/
不過因為建管處放出來的都是使用執照的掃描圖檔,要用 OCR 掃出裡面完整資訊難度真的很高,因此我爬完後就有點不知道該怎麼處理了,雖然說當初爬的目的是想做台灣豪宅通App XD
就變成我只有 「地址」、「使用執照編號」、「圖片檔」資訊,其實也想不到只有這三個資訊能做什麼應用

後來我還有去爬台北市門牌資料爬出的資料)把跟使用執照的地址資訊結合起來,放到 Fusion Table
,所以可以在 Fusion Table 上面從地圖上找這個點的建築執照是哪一張。
gugod 提到建築年份地圖,我就想到這份資料可以用在這裡了,正好使用執照編號的前幾碼就是年份。



我先用 Fusion Table 的可以改變標示點顏色的功能,想說能不能解決,所以就生了一張年份地圖

但是 Fusion Table 的 marker 顏色無法很彈性自訂,所以就變成雖然依照年份有不同顏色了,但是顏色無法一眼看出新舊關係,於是我就把腦袋動到 CartoDB 上了

我先把 Fusion Table 的 csv 下載下來,再 import 進 cartodb ,不過 cartodb 免費帳號有 5MB 的限制,而下載下來的檔案就 11MB 了,所以我再稍微處理了一下,把沒有座標的點去掉,地址欄位拿掉,使用執照編號直接改成年份,總算把檔案壓到 5MB 以下了,再匯入進 cartodb 就可以看到所有點了。(配上 CartoDB 的 geo reference 功能之後,整個 table 大小就增加到 11MB 了,所以一個免費 account 就被鎖死不能再上傳新資料了 XD)

然後昨晚 clkao 給了一個 Colorbrewer: Color Advice for Maps 有一些顏色可以參考在地圖上顯示資訊,然後我拿了其中一組,於是用 CartoDB 的 CartoCSS 功能,產生了這組 CSS

於是一切就完工了!




也歡迎大家可以把這些資料拿去試試看套用其他顏色,看看能不能讓他更容易被看,另外其實各縣市都有提供「使用執照」和「門牌資訊」,只是每一個縣市的網站都是給不同的包商做的,所以每個都要重新爬一次,如果要做其他縣市的地圖的話,可能就要整個重新爬一次。

而且台北市提供的門牌資訊只有門牌所在的座標點,無法得到建築物輪廓資訊,因此我做的城市建築年齡地圖就只能用點來表示了

像中正廟因為 97 年時曾經增建過有發新的使用執照,因此在地圖上顯示的時間是 97 年,這個就比較可惜了(中正廟相關使用執照:690733 690734 731346 760724 760760 970187)
另外大直一帶都沒有點好像是因為我爬台北市門牌資料沒有爬完整造成的,這個我就不太確定了。




來讓大家看看世界各城市的範例吧:
Portland, Oregon: The age of a City

Buildings in the Netherlands by year of construction

Block by Block, Brooklyn’s Past and Present

, , , , ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(2) 引用(0) 人氣()

在 COSCUP 第二天中午因為跟 g0v 的大大們一起吃飯聊天,其中聊到了台灣媒體亂象
之後我就一直思考台灣的媒體有哪些問題,能不能各個擊破一一解決

其中有想到的問題包括
1. 新聞錯誤百出未經查證 (這個問題是客觀的,只要拿證據或是原始來源就可以打臉了)
2. 新聞價值觀偏頗,刻意引導讀者思考方向 (這個就比較難處理了,只能列出其他面向的說法鼓勵大家都看看了)
3. 新聞生命週期太短,往往喧螣一時,結果一個月後就被大家給遺忘,尤其是 Facebook 的出現更助長了這種風氣,很多消息超過12小時可能就消失無蹤了。

這幾個問題都滿需要被解決的,可是要怎麼解決呢?

晚上我突然想到一個方法,馬上在微網誌上面貼了出來

如果弄一個叫「我Lag了」的Facebook專頁,他每天只做一件事,就是分享四大報頭版,但是...他分享的是30天前的,這樣子不知道對於降低大家的新聞遺忘症會不會有幫助...

這時候就在想像如果有個這樣的粉絲專頁會發生什麼事?

大家很常會發現「幹!原來30天前的頭條新聞是這個?我怎麼忘了」「對喔,30天前那麼大的新聞,現在到底怎樣了?後續呢?」
這樣子對公民健忘症是不是一帖良藥?

於是心動不如馬上行動,趕緊在#g0v IRC 問有沒有人知道哪邊有四大報頭條的整理資訊,然後開始寫程式來爬,當晚就先弄出了一個 http://oldpaper.g0v.ronny.tw/ 把整理好的資料列出來,接著就是註冊一個粉絲專頁,原先想的「我Lag了」 感覺名稱不夠直觀,想說那叫LagNews好了,但是還是要有個響亮的中文名字比較好,想到 PTT 上很常故意把你Lag了說成你腿了,那就叫腿新聞吧! 於是粉絲專頁開好,圖片就去 Google Image 搜尋有開放使用授權的圖片並搜尋 Leg 和腿,就挑了一張照片使用,粉絲專頁就開好了!

再來是寫好發送訊息到 Facebook 粉絲專頁的程式,一切就打完收工了!!

LagNews腿新聞  

程式碼我 open source 在 https://github.com/ronnywang/lagnews 給大家參考囉!

希望能透過 LagNews腿新聞,逐步改善公民新聞健忘症,那麼再來剩下的問題就是媒體的客觀錯誤以及立場偏頗了!

這週六(8/10) g0v 第四次國民大會黑客松,我提了「新聞小幫手」的想法,希望能夠解決客觀錯誤的問題!
讓我們更進一步邁向健全的公民社會!

Posted by 榮尼王 at 痞客邦 PIXNET 留言(3) 引用(0) 人氣()

N5001UWKAP  

求職小幫手也有 WebApp 版本了,用手機也可以使用求職小幫手囉!
網址是 http://jobhelper.g0v.ronny.tw/mobile ,或者可以掃描上面的二維條碼直接進入喔

感謝 nansenat16 花時間製作,nansenat16 也有把他 open source 在 GitHub
另外 nansenat16 也有製作 Android App 在 Google Play ,真的是太感謝了!

因為我只有 iPhone ,我這邊先教一下怎麼在 iPhone 把他作成 WebApp 的方式

1. 先用 iPhone 瀏覽器開 http://jobhelper.g0v.ronny.tw/mobile ,可使用上面的 QRCode,畫面如下:

IMG_2484  
  

2. 點選最下面一排的中間的按鈕

skitch_iphoto.export.skitch 2  

3. 進到動作選單之後,往右拉

skitch_iphoto.export.skitch  

4. 看到求職小幫手圖示和「加入主畫面」了吧,按下去吧

skitch_iphoto.export.skitch 3  

5. 選擇一個你想要的顯示名稱,並且按下新增

4  

6. 成功囉!以後就可以直接使用了!

5  

祝大家使用的開心,並且找到一份好的工作!

, ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(1) 引用(0) 人氣()

1211185542  
「日光節約時間」就是在每一年的一段時間把時鐘調快一小時,讓一天的生活作息能夠接觸到更多的陽光,換來的是可以節省燈光照明的電力
根據 wikipedia 上所記錄,最早是在 1916 年德國開始實施
中華民國在民國34年到民國50年、民國63年、民國68年都實施過日光節約時間,不過後來都因效果不佳而取消。
下面用一些數據來說明一下日光節約時間的效果。

這邊我用倫敦、華盛頓、莫斯科、柏林、北京、台北幾個城市來舉例一下

倫敦、柏林:3月最後一個星期日~10月最後一個星期日
柏林:2012年開始永久日光節約時間,不再回調(等於時區移動了一小時)
華盛頓:3月第二個星期日~11月第一個星期日
北京、台北:無日光節約

城市 柏林 倫敦 莫斯科 華盛頓 北京 台北
經緯度 52.5N
13.4E
51.5N
-0.1W
55.7N
37.6E
38.5N
77.0W
39.9N
116.4E
25.0N
121.5E
日出日落 6/21
夏至
03:43
20:33
16h50m
03:43
20:21
16h38m
03:44
21:17
17h32m
04:43
19:37
14h53m
04:46
19:46
15h00m
05:05
18:47
13h41m
4/1 05:41
18:41   13h00m
05:36
18:34   12h58m
06:01
19:07   13h06m
05:52
18:32   12h39m
05:59
18:38   12h39m
05:46
18:10   12h24m
以上時間是沒算日光節約時間的時間
假設一般人作息時間是早上七點到晚上十一點
6/21
夏至
無日光節約日夜時間 日13:33
夜2:27
日13:21
夜2:39
日14:17
夜1:43
日12:37
夜3:23
日12:46
夜3:14
日11:47
夜4:13
有日光節約日夜時間 日14:33
夜1:27
日14:21
夜1:39
日15:17
夜0:43
日13:37
夜2:23
日13:46
夜2:14
日12:47
夜3:13
減少黑夜 41% 38% 59% 30% 31% 24%
4/1 無日光節約日夜時間 日11:41
夜4:19
日11:34
夜4:26
日12:07
夜3:53
日11:32
夜4:28
日11:38
夜4:22
日11:10
夜4:50
有日光節約日夜時間 日12:41
夜3:19

日12:34夜3:26

日13:06
夜2:54
日12:32
夜3:28
日12:38
夜3:22
日12:10
夜3:50
減少黑夜 24%

28%

26% 23% 23% 26%

假設一般人作息時間是早上六點到晚上十點

6/21夏至 無日光節約日夜時間 日14:33
夜1:27

日14:21
夜1:39

日15:17
夜0:43
日13:37
夜2:23
日13:46
夜2:14
日12:47
夜3:13
有日光節約日夜時間 日15:33
夜0:27

日15:39
夜0:21

日16:00
夜0
日14:37
夜1:37
日14:46
夜1:14
日13:41
夜2:19
減少黑夜 69%

79%

100% 33% 45% 29%
4/1 無日光節約日夜時間 日12:41
夜3:19

日12:34
夜3:26

日13:05
夜2:55
日12:31
夜3:29
日12:38
夜3:22
日12:10
夜3:50
有日光節約日夜時間 日13:00
夜3:00

日12:58
夜3:02

日13:06
夜2:54
日12:39
夜3:21
日12:39
夜3:21
日12:24
夜3:36
減少黑夜 10%

12%

0.5% 4% 0.4% 6%

以上時間是來自 http://www.timeanddate.com/

在 20 世紀初期,照明還是用舊型電燈或燃油的時代,一般家中耗能最高的就是照明了,所以減少黑夜時間把作息移到有陽光的時間是可以減少耗源的方式
像是英國在 1916 年實施日光節約時間就減少了 15% 的燃煤和電力(但是電商也藉此趁機漲價 15% ,老百姓花費沒變)

但是現在 21 世紀,空調相當的普及,增加一小時的白天時間就相當於增加一小時的空調時間
因此日光節約時間是否有辦法節約能源已經有待再商榷


至於台灣本來緯度就不高,實施日光節約時間的效果不會比高緯度國家好,反而還要增加很多社會成本去處理調整一個小時的狀況
之前國民黨中常委邱復生提議恢復日光節約時間,還是不要比較好吧

美國白宮的 We The People 線上請願也已經有三萬多人請願要求白宮取消日光節約時間(不過請願門檻是十萬人)

, ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

之前在 Open Data Day 提出了求職小幫手之後,有滿多人對這個想法感興趣的,不過也因為我只有在活動當天提出這想法,並且 demo 了很簡單的版本,如果當天沒參加活動的人,搜尋「求職小幫手」應該找不到任何相關資訊吧,所以我決定在我的部落格上面大概介紹一下這想法讓有興趣的人可以了解。

2011年6月29日勞基法修法,增加「有前二項規定行為之一者,得公布其事業單位或事業主之名稱、負責人姓名,並限期令其改善;屆期未改善者,應按次處罰。」,因此各地勞工局每月必需要公布開罰名單,並由勞委會設立公布專區連結到各地勞工局。這些資訊其實對基層勞工滿重要的,因為他可以知道哪些公司是有超時加班或是不按規定給付加班費之類資訊的,對於求職者也相當重要,若是知道這資訊他在評價各工作機會時心中可以多一把尺。但是這些資訊 104 之類的求職網頁並不會直接揭露給求職者看,大部份求職者也不知道政府有公開這些資訊。如果今天能有一個求職小幫手工具,可以幫你整理政府所公開的一些公司資訊,相信能增加大家選擇到較好工作的機會,於是我就生出了求職小幫手的想法。

至於目前 demo 出來的半成品大概長成下面這個樣子:

螢幕快照 2013-03-25 上午11.50.22  

已經可以支援 104, 1111, yes123, 518 四個網站。

不過大家在 Google Play 要找應該找不到求職小幫手,因為我還沒有公開,沒公開的主要原因是我雖然已經把功能完成,卻缺少 content。我的 demo 只有處理台北市勞工局公布的資料,這樣的資料是相當少的,但是如果有進到勞委會公布專區看的人應該就會知道,要把公布資料完整抓出來真的不算是一個小工程,主要遇到了幾個困難

  1. 有些勞工局根本沒有公布資料,Ex: 新竹科學工業園區管理局
  2. 有些勞工局資料幾萬年沒更新
  3. 各勞工局公開方式不同,有寫在網頁上、有PDF
  4. 有些勞工局只公布最近一次的資料,過去的資料就找不到了

要把這些資料整合起來就已經是很麻煩的一件事了,而不做這些事,公開一個只有肉體沒有靈魂的求職小幫手感覺對大家也沒有什麼幫助,反而可能會讓裝了的使用者覺得不實用馬上就刪掉了,因此至今我仍未將求職小幫手公開。

目前求職小幫手的程式碼我有公開在 Github 上面 https://github.com/ronnywang/jobhelper如果想要實作類似功能卻不知道如何下手的人可以把他抓回去看看
程式碼不多,大致上是修改自 Chrome Extension Sample 上面的 Pageaction by content

所以目前求職小幫手的進度就是在想辦法補充內容中,目前電資工會正幫忙發文給各勞工局希望能拿到更詳細的資料,希望讓內容豐富點之後就可以公開給求職者使用了,

我目前開了一個 Google Groups 來討論求職小幫手,如果有任何想法都歡迎上去討論囉!

, , , , , , , ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(6) 引用(0) 人氣()

昨晚睡覺睡到一半被簡訊聲吵醒,收到一封完全看不懂的簡訊
電話號碼: +62 811 1682561

內容是

Selamat.! Anda terpilih sebagai nasabah TKI Taiwan mendapat hadiah cek tunai NT$.250.000, dari "BANK BRI" Info hub: +6282332222289

Pengirim:
BANK BRI

看到 NT$.250.000 就覺得應該是詐騙簡訊了,不過除了 Taiwan, NT$.250.000, BANK, Info hub 以外,其他單字我都不認得..
今天再拿去給辜狗小姐翻譯一下,翻譯如下:

安全。您被選為台灣TKI客戶獲得的獎金NT$.250.000檢查,從“BANK BRI”信息中心:6282332222289

發件人:
銀行BRI

哈哈..第一次收到印尼文的詐騙簡訊,記錄一下

,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

最近開始玩一些 Open Data 的東西,除了爬實價登錄以外,開始想爬一些好玩的東西來看看
這次我爬了台灣經濟部商業司登記的公司資料,找出 46 萬家公司的資料(照商業司的資料目前有六十幾萬家公司,所以我還有十幾萬家公司的資料是沒有找到的,我還要想想看是哪些我沒找到的)
我找出來的資料包括公司的代表人、資本額、營業項目、經理人名單等...

這些都是公開資料,所以我爬這些資料做些統計應該不違法吧

這邊我先公開一下,我這些找出的資料中, 46萬家台灣公司,資本總額前十名的公司是哪十家吧!
我貼的資料會包括該公司的統一編號,有興趣的人可以到 http://gcis.nat.gov.tw/pub/cmpy/cmpyInfoListAction.do 把統一編號輸入進去確認看看資料是否正確。

其實這數字不代表他就是台灣最大的,因為這邊的資本額資料只是單一公司,但是很多公司都是屬於同一個集團,而該集團的老闆都會是同一人,如果以集團來算的話,前十名可能就不是這十家了。另外我列出的董監事主要代表是以董監事名單依照股權列出來的,不代表這就是那個法人所掌控的公司, 所以以下十家僅供大家參考。

第十名  52242444 台灣自來水股份有限公司
資本總額: 1375億元
實收資本額: 1285億元
代表人: 阮剛猛
董監事主要代表: 經濟部

第九名 80333992 中國信託金融控股股份有限公司
資本總額: 1500億元
實收資本額: 1316億元
代表人: 辜濂松
董監事主要代表: 70845988宜高投資股份有限公司, 23360934仲成投資股份有限公司, 53325695長基投資有限公司

第八名 30414175 中國鋼鐵股份有限公司
資本總額: 1700億元
實收資本額: 1531億元
代表人: 鄒若齊
董監事主要代表: 經濟部, 勞工保險基金, 高雄市中國鋼鐵股份有限公司企業工會, 70748331景裕國際股份有限公司, 97159912群裕投資股份有限公司, 97159878高瑞投資股份有限公司, 28292730鴻高投資開發股份有限公司

第七名 89390656 南亞科技股份有限公司
資本總額: 1910億元
實收資本額: 1866億元
代表人: 吳嘉昭
董監事主要代表: 75370905南亞塑膠工業股份有限公司, 14001199福懋興業股份有限公司,20807329培仁股份有限公司

第五名 70827383 中華開發金融控股股份有限公司
資本總額: 2000億元
實收資本額: 1445.6億元
代表人: 陳木在
董監事主要代表: 12650176興文投資股份有限公司, 03557311臺灣銀行股份有限公司, 03705903兆豐國際商業銀行股份有限公司, 22522756國亨化學股份有限公司...

第五名 86517321 萬泰商業銀行股份有限公司
資本總額: 2000億元
實收資本額: 162.3億元
代表人: 盧正昕
董監事主要代表: 荷蘭商 S.A.C.PEI Taiwan Holdings B.V.

第四名 11085292 中華映管股份有限公司
資本總額: 2450億元
實收資本額: 647.9億元
代表人: 林蔚山
董監事主要代表: 11083673中華電子投資股份有限公司, 21222725仁寶電腦工業股份有限公司, 27335280綠能科技股份有限公司

第三名 47217677 聯華電子股份有限公司
資本總額: 2600億元
實收資本額: 1295億元
代表人: 洪嘉聰
董監事主要代表: 70761592迅捷投資股份有限公司, 22099202矽統科技股份有限公司, 財團法人聯華電子科技文教基金會

第二名 22099131 台灣積體電路製造股份有限公司
資本總額: 2705億元
實收資本額: 2592億元
代表人: 張忠謀
董監事主要代表: 行政院國家發展基金管理會

第一名 03795904 台灣電力股份有限公司
資本總額: 4000億元
實收資本額: 3300億元
代表人: 黃重球
董監事主要代表: 經濟部, 03557311臺灣銀行股份有限公司, 03700301臺灣土地銀行股份有限公司

以上就是單純以資本總額排序的前十名公司,以上資料不代表前十大企業,因為一個企業下面可能有很多家不同公司的,另外董監事名單不代表這家公司是掌握在這些董監事手中,可能只是這些法人在董事名單中佔相對比較多股權。我自己對公司組織這方面比較沒那麼多了解,所以純粹以資本總額做排序列出前十名。如果有人對公司組織更了解的,應該能跑出更有意義的排名出來,我這邊應該下週就會丟出我爬出來的 46萬 個公司的公開資料,也希望能有其他更了解公司組織的人能丟出更有意義的統計數據出來了!

PS: 我也希望看這篇文章的人能夠抱持著懷疑的心來看,你可以假設我也許是被某個財團某個政黨買通的情況下寫出了這篇文章,因此裡面可能有偏頗的地方,若是你有懷疑的地方,可以自己試著去查證看看,並且在下面留言的地方留下你的看法。
因為我覺得現在很多台灣人會無條件接受媒體或是部落客給你的資訊,我還是希望大家能有對資料來源有所懷疑的心態來看所有的東西,這樣子大家才比較不容易被媒體輕鬆的牽著走。

Posted by 榮尼王 at 痞客邦 PIXNET 留言(12) 引用(0) 人氣()

今天參加青平台OpenData 講座 – 「開放資料」與「開放街圖」 當地圖不再只是地圖時
這個講座主要是在分享 Open Street Map (以下簡稱OSM)
我覺得我有得到很多想法,我也在我個人的 TODO 清單又加了一些我想要做的東西
不過也因為我在聽到一些事情有些疑問我發問了兩次,事後想想我覺得我發問方式好像會給人一種感覺
就是「這個問問題的人是心裡覺得 Google Map 就很夠用了,幹嘛來用 OSM」
我想要澄清一下,因此來貼這則部落格文,並且說明我覺得 OSM 應該怎麼做比較好。

我先說明一下,我是反對 Google Map 獨大的人,也很希望 OSM 計劃能夠茁壯
而我對於反對 Google Map 獨大我的具體作法是
當我用手機要找地方時我會先開 Apple Map ,找不到我要的地方我再改用最近上架的 Nokia Here Map 
再找不到我逼不得已才會去用 Google Map
目前雖然其他兩家圖資都遠不如 Google Map ,但是等他們未來越來越強,我就可以越來越不需要用 Google Map
也算是給其他家個機會
至於 OSM 我是不知道有沒有類似 Google Map/Apple Map/Nokia Here Map 這種基本應用
所以我目前沒在用 OSM
如果有的話,我也會讓他插隊在前面先來用他。 

我個人認為,圖資可以被分成兩種
一種是「基本圖資」 ,像是疆域圖、水文、、道路圖、重要地標...
另一種是「應用圖資」,像是房價實價登錄資料、郵筒位置、無障礙評比地圖、原住民文化說明地圖、某企業分店位置...
只是基本圖資與應用圖資有時候分野會很模糊,例如說便利商店位置分布能不能算是基本圖資?郵筒位置算不算基本圖資? 

OSM  的目標應該是希望將地球上所有的圖資都以 open data license 讓全世界都可以取用
用 wiki 的形式讓全世界都能編修
這個方向很完美,我也樂見其成

我今天的第一個發問,是針對 Dennis 在分享他建立郵筒地圖的時候,因為他編修過程是用 Google Map ,再把結果丟到 OSM 上
這樣子其實有點吊詭,就是講了這麼多「不該讓Google Map獨大,請大家來用OSM」,結果過程中還是用了Google Map

再來是其中有一位老師是在做原住民文化地圖的,他目前的作法是產生 KML 在 Google Map 上顯示
我的第二次發問簡單說是想問,有什麼辦法可以說服這位老師把 KML 改成在 Open Street Map 上面顯示?

其中我第一個問題其實心裡本來就有答案了,答案就是 OSM 現在就是基本圖資不足,無法作到類似 Geocoding 的功能(將地址轉換成經緯度或是經緯度轉換成地址),因此除了 Google Map 似乎真的沒什麼好的選擇,未來 OSM 基本圖資豐富了,這個問題自然就迎刃而解。

而第二個問題的部分,我想了想之後我覺得我想錯方向了,也許 OSM 的人也跟我一樣想錯方向
現在那位老師是用 KML(原住民文化地圖) + Google Map 來呈現
與其說服他把這組合改成 KML(原住民文化地圖) + Open Street Map
是不是改成 Open Street Map(原住民文化地圖) + Google Map 會更好?

推廣 Open Data 的人總是會想要一步到位,希望全世界都可以把全部東西都 Open
因此會希望全世界的開發者馬上都把 Google Map 全部改掉
但是做應用的開發者心裡想的,卻是希望我服務能趕快給別人看,我底層用 Google Map/Apple Map/Bing Map/Open Street Map 完全不是重點
我知道 Google Map 未來可能會在我變大的時候要跟我收錢,那我那時候再換掉不就得了?
為什麼我要為了「給 Open Data 一個機會」而一開始就把底層換成目前圖資完整度以及基本應用還有待進步的 OSM
結果是讓使用者體驗變差?

與其這樣,我覺得要推廣 Open Street Map 應該轉個方向
今天因為 Open Street Map 的基本圖資還不夠完備,因此我不強求你要完全使用 Open Street Map
至於你的基本圖資的部分用 Google Map 也沒有關係
但是希望你能夠將你所產生的應用圖資(Ex: KML) 丟上 Open Street Map
這樣子你的圖資也能夠被大家廣為使用。
而且今天應用圖資多了,自然就可以透過這些應用圖資還原出更多的基本圖資出來。

至於基本圖資的部分,今天的講座主要講的是希望大家一起來畫地圖
這件事又回到 Open Gov Data 的議題了
其實剛剛講的資本圖資像是疆界、河流、道路、地標這些資料,政府手上全部都有
只要政府願意 open ,這部分幾乎是瞬間解決
而且政府也有定期維護資料正確性的的義務
如此一來,Open Street Map 的基本圖資完備了,那麼把 OSM(原住民文化地圖) + Google Map 改成純 OSM 又有什麼問題呢?

結論就是,我覺得台灣的 OSM 現在假如想要成長,優先應該做的事有兩個
1. 鼓勵大家把自己的應用圖資推上 Open Street Map
2. 推動政府 Open Data 以增進 Open Street Map 的基本圖資
至於叫開發者把基本圖資都從 Google Map 轉移到 Open Street Map 這件事還是之後再說吧
這樣做會讓大家比較容易第一時間就對 Open Street Map 有所排斥,結果反而收到反效果。 

, , , ,

Posted by 榮尼王 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()