群眾外包的訊息平台 — Ushahidi

Ushahidi 是一套著名的群眾外包 (Crowdsouring) 平台,被運用在許多世界上重大的災難事件中,它的出現是因為2007年非洲肯亞總統大選出現爭議而暴動,為收集肯亞各地暴動資訊,Erik Hersman等人建立了一個以電子郵件和簡訊方式收集暴動事件之資訊,並顯示於Google Map 上,此平台並命名為 Ushahidi ,即為非洲斯瓦希里語 (Swahili) 的「證詞 (testimony)」或「證人 (witness) 」之意,而 Ushahidi 以收集群眾所提供的災難資訊,並繪製於地圖上的方式,也稱為災難地圖 (Crisis Map) 。
Ushahidi平台建立於 Kohana 網頁架構,也就是一個PHP 5 為基礎,提供許多豐富的套件以用來建立網頁, 為 CodeIgniter 架構 (PHP 5 開發環境) 的一個分支。在簡訊收集方面,Ushahidi並內建 Nexmo,用來處理大量手機簡訊(Shot Mobile Message)的API,以及 Clickatell 來提供收集簡訊閘口 (gateway),此外,Ushahidi 也常使用 FrontlineSMS 來收集使用者所發送的簡訊。在地圖顯示方面,Ushahidi使用OpemLayers套件為災難訊息地理視覺化的工具,使用者透過這個套件可以將災害訊息定位,所收集的災難訊息也可以分門別類地顯示於地圖上。圖1為我們所建立的測試平台。

圖1: 我們所建立的Ushahidi測試平台
圖1: 我們所建立的Ushahidi測試平台

SwiftRiver是擴充Ushahidi資料收集的系統,該系統結合自然語言處理和資訊探礦的處理套件,能分析使用者所上傳資料,如Twitter和簡訊,在短時間內,幫使用者分類並提供使用者充份的背景資訊,讓使用者更容易提供資訊,另一方面,資料收集者也因為充份對上傳的災害資訊分析,能有效地歸類整理災害資訊,而使所收集的資訊能加以利用,因此SwiftRiver被定位為具有所生產一個智慧且即時的資料收系統。SwiftRiver具有三個主要功能:1) 組織未結構化資料、 2) 條件式過濾和即時分辨上傳訊息的優先程度、 3) 加入有意義的脈給 (context) ,如位置,圖2為SwiftRiver的使用介面,對於來自於Twitter的事件報告,可以進行內容的過濾與辨識,以利後續分類及訊息分送。

圖2: SwiftRiver的使用介面
圖2: SwiftRiver的使用介面

Ushahidi在世界各地及重大災難事件的使用

(1) 2010年海地地震

在2010年海地地震發生沒多久,哈佛大學人道計畫(Harvard Humanitarian Initiative) 發起人之一, 利用Ushahidi 開啟了一個三個單位聯合的海地人道救援計畫,包含美國塔夫茲大學佛萊契爾法律外交學院(The Fletcher School of Law & Diplomacy at Tufts University)、哥倫比亞聯合國人道事務協調辦公室(UN OCHA/Colombia)和危機資訊製圖者國際網絡(the International Network of Crisis Mappers (CM*Net)),在該計畫開始後的幾個小時,即有許多的人道救援和技術的工作者加入,近40000筆的事件報告被傳送到這個海地地震的Ushahidi,之中有約4000筆的事件被標示於地圖中,圖3這個海地地震的Ushahidi。

圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi
圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi

(2) 2011年紐西蘭基督城地震
在2011年2月22日的紐西蘭基督城地震後24小時, 基督城復原地圖(Christchurch Recovery Map) 即利用 Ushahidi 建立起來,該網站標示了重要物資訊息,如食物、水、廁所、燃料、ATM和醫藥用品,其訊息由Twitter以#eqnz這個雜湊標籤、簡訊和電子封件來收集,這個網站由一群網站專業工程師和志工來建立與維護,如圖4所示。

圖4: 基督城復原地圖
圖4: 基督城復原地圖

(3) 2012年東日本大地震

2012年東日本大地震之後,Ushahidi被使用來交換傳遞地震災情與救援相關訊息。圖5為利用Ushahidi建立的日本復原地圖。

圖5: 日本復原地圖
圖5: 日本復原地圖

(4) 2011年美國密蘇里河洪水

MightyMoRiver 計畫是使用 Ushahidi 為 Crowdmap.com 服務的平台來追蹤2011年美國密蘇里河洪水的災害事件。

圖6: 密蘇里河洪水事件災害地圖
圖6: 密蘇里河洪水事件災害地圖

(5) 馬其頓共和國的貪腐事件報告

透明觀察計畫是使用 Ushahidi平台來追蹤馬其頓共和國的貪腐事件, PrijaviKorupcija是一個由馬其頓國際透明組織(Transparency International – Macedonia)和國際關係中心(Center for International Relations)聯合的計畫,旨在使公民可利用手機簡訊、電子郵件和twitter的雜湊標籤#korupcijaMK 來報導馬其頓貪腐事件。

圖7: 馬其頓共和國的貪腐事件地圖
圖7: 馬其頓共和國的貪腐事件地圖

群眾外包的交通時況—Google Map traffic layer

日前與友人聊天時談到Google Map的交通時況是收集 Android的智慧型手機上的資訊,當時有點驚訝,我一直以為Google Map是使用交通部的TMC(即時交通資訊廣播),經過一番調查與測試,沒錯! Google Map 上的交通時況就是Crowdsourcing,就是千千萬萬Android 用戶貢獻的,幾點提出來來大家分享:

一、Google Map Traffic 所涉及的範圍比交通部的TMC還廣

TMC在許多都會區道路上都有架設收集的點,但鄉村地區則不足,但Google Map上卻常常有資訊,舉例在草屯鎮,在交通部服務e點通 的地圖上中二高和水沙璉高速公路都有會交通路況,但草屯市區道路看不到路況資訊,在TMC的建置計畫中也沒有草屯鎮道路的資訊,但在Google Map上,有幾條道路顯示出路況。

Screen shot 2013-05-10 at 2.05.54 PM
TMC
Screen shot 2013-05-10 at 2.06.05 PM
Google Map Traffic

 

 

二、Google Map 導航的時間估算變得比較準確

以前使用Google Map 路線規劃,時間的預估和實際狀況有時候因為塞車,使得交通時間變長,曾幾何時,Google Map路線規劃也把交通狀況考慮進去,使得路線規劃的時間變得比交符合現況,或許從Google Map的blog中可以看出一底端倪。從Mashable的這篇報導中,更加讓人確信Google Map Traffic Data是使用Android用戶。

Data is gathered through third-party services and through information from Android users who have opted in to the My Location feature on Google Maps. Google would be able to tell, for instance, if there were several Android owners moving slowly on the freeway and determine that there was traffic slowing them down. The more people opting into the service in the area, the better the traffic information available will be.

 

三、Google Map Traffic會出現一些與現實路況不符的情形

根據觀察,Google Map交通時況在中研院門口附近於中午時候,常有塞車的情況,但事實是如此嗎? 想想中午的時候有許多人用“走”出去吃飯,如果Google Map交通時況是集合Android GPS訊號而轉換得到的資訊,這些被標示塞車的路段,可以合理的被懷疑是因為集合多數人”走”速度,而讓Google Map交通時況的判斷為塞車?

Screen shot 2013-05-10 at 1.41.21 PM
中午時,中研院附近的Google Map Traffic

 

Enhanced by Zemanta

[試作] WebGL在Geovisualization上應用

Google Earth是一個3D視覺化的地理空間資訊展示平台,無庸置疑的是它的提供高解析度衛星影像,且虛擬實境般的地理空間資訊瀏覽環境,令許多人愛不釋手,其實由NASA的World Wind也是一個相當不錯的3D視覺化的地理空間資訊展示平台,而且是open source。這二個平台都是獨立的平台,雖然Google Earth有整合在網頁瀏覽器中,對於一個本身就是3D視覺化的地理空間瀏覽器而言,要塞入另一個瀏覽器,總是卡卡的。所以有沒有輕量一點的、且原生於網頁技術的3D視覺化工具可以用來做地理空間資訊視覺化呢?

隨著網路技術的發展,應該會有許多工具可以用,但找到許多與WebGL相關的,所以先來看看WebGL可以做什麼事。

根據Wikipedia的介紹,WebGL (Web Graphics Library) 是一個用來顯示互動式3D和2D圖形的JavaScript API,不用plug-in就可以在網頁瀏覽器中使用。WebGL的元素(elements)可以鑲嵌於其它HTML元素,且組合成網頁中的一部份,也因為WebGL與網頁瀏覽器中GPU的標準相容,因此可以加速圖形處理能力。目前WebGL的設計和維護都是 Khronos Group 。

OpenWebGlobe 簡單地說,就是一個以WebGL做的Google Earth,可以套疊上高解析度的衛星影像、用DTM把地形撐起來、可疊上3D建物、POI和文字資訊等,功能十分完善,OpenWebGlobe是以MIT License 釋出的Open source,且提供SDK給開發者。

OpenWebGlobe
以WebGL為基礎的OpenWebGlobe

 

另外,也有相對輕量化的WebGL工具,讓網頁開發者可以用於網頁中地理空間資料的3D視覺化。WebGL Globe是Chrome的一項實驗計畫,其中有許多很Cool的demo,按照介紹就可以自已做出一個地理空間資料的3D視覺化。下圖是一個簡單的試作,利用NSAS MODIS衛星影像中所採集的地面溫度,經過一番資料的處理後,地面溫度的資料根據設定的顏色顯示於這個球上,可以旋轉、放大、縮小控制瀏覽。

WebGL Globe
以NASA MODIS地面溫度的WebGL Globe試作

WebGL Earth 是強調地圖或衛星影像的套疊,如套上BingMapOSM

WebGL Earth BingMap WebGL Earth OSM

Enhanced by Zemanta

如何安裝4store

所謂的「triplestore」也就是用來儲存的RDF的資料庫,並可以應用類似SQL的語言來查詢。現在已經有許多發展不錯的triplestore。這裡介紹一個輕簡的triplestore—4store的安裝。

1.安裝相關套件

sudo apt-get install build-essential libpcre3-dev libglib2.0-dev ncurses-dev libreadline-dev libtool libxml2-dev libxslt-dev automake git-core

2.安裝raptor

wget http://download.librdf.org/source/raptor2-2.0.0.tar.gz
tar -xvzf raptor2-2.0.0.tar.gz
cd raptor2-2.0.0

3.安裝rasqal

wget http://download.librdf.org/source/rasqal-0.9.22.tar.gz
tar -xvzf rasqal-0.9.22.tar.gz
cd rasqal-0.9.22
./configure –enable-query-languages=”sparql laqrs” && make && sudo make install

4.安裝4store

git clone git://github.com/garlik/4store.git
cd 4store
git checkout a907f3e0a3717c16dabe383d1834df6f8090b97a
./autogen.sh
./configure –enable-no-prefixes
make && sudo make install

5. 測試4store

make test

 

 

如何在JSOM增加一個公開的WMS圖層

打開prefernece(偏好設定)後,在對話頁面中有一個WMS/TMS的選項。選定後,有一堆預設的WMS可以選擇,一般而言,Bing和Landsat的WMS 已經是加入的,所以在預設的介面中可以加入Bing或Landsat的衛星影像。若有公開的WMS可以使用,即可以在此加入,按右下方有一個”+”符號,即可加入自已想加入的 WMS圖層,如圖1所示。

 圖1: 開啟WMS對話框

按了增加”+”後,另一個對話框會跳出。在WMS分頁的Services URL (服務網址)中,給定一個名稱,如Taiwan_WMS_Pop,貼上提供服務的網址,如“http://211.21.33.103:8080/geoserver/wms?service=WMS”,這是是用台灣MAKOCI所公開的WMS服務,圖2所示。

 圖2:輸入WMS 網址

按一下Get Layers(取得圖層),JSOM 連接到該WMS後,會自動取得圖層的資訊,並列出來,如圖3。選擇一個圖層,如WGS84_Population,並給定一個圖層名稱,如按”OK”,並回到主畫面。

 圖3: 列出WMS所提供的圖層

在主畫面中,Imagery(影像)的下拉單中會增加一個選項,如圖4。按一下這個新增的影像選項,WMS的圖層即載入,如圖5所示。

圖4: WMS圖層選項加入Imagery的下拉單中。

圖5: WMS的圖層加入編輯環境。

什麼是地理標記語言? What is Geography Markup Language (GML)?

地理標示語言(Geography Markup Language,GML) 是OGC所提出的一種對地理物件進行編碼的語言。就資訊技術層面而言,GML是以可擴展標示語言(eXtension Markup Language,XML) 為編碼基礎的語言,主要對於地理資訊中地理圖徵(feature)的空間和非空間屬性之模式化、傳輸和儲存,並且達成下列目的(OGC,2003):

(1)透過網路對於分享和交換已編碼的地理資訊。
(2)對於不同領域的論述之地理語彙表達。
(3)對於地理的網路服務之資訊元素表達。

地理現象是複雜、多樣和多尺度的,要準確且有效率的在電腦環境中,甚至網路世界中操作,必須轉化於真實世界概念中地理資料模式(geospatial data models),以作為人與電腦溝通地理資料的中介。GML的應用並扮演了二個重要角色(OGC,2005) ,一是表現原始資料模式;另一是在地理空間資料基礎設施(Spatial Data Infrastructure,SDI)架構下,以GML文件在政府組織和商業團體中相互分享。目前實用性較高GML版本為GML 2.0和GML 3.0,其中GML 2.0符合地理空間資料庫或GIS軟體所奉行的簡易圖徵標準(Simple Feature Profile),同時也被眾多商業軟體所採行,如ESRI ArcGIS,然而GML 3.0則加強地理空間資料之表達上所需的型態與方式,支援了多種物件(objects)以描述地理資訊之位相關係、三維(3D)幾何性質、座標參考系統、時間屬性值、多種比例尺、metadata、網格(grid)資料、和對地形及區域做視覺化處理所需的預設樣式,且GML 3.0也大幅度地擴展內建元素(built-elements),這也是GML提供地理應用開發者最主要的部份。GML 3.0提供29個核心綱目(core schemas)於使用者對地理資料建立各自知識領域或專業領域的地理模式時使用,如此豐富地理描述語彙包含了超過10,000條的編碼充份地提供各知識領域所需。而GML 3.0提供地理物件的編碼包含(OGC,2003):

(1)地理特徵(geographic features),包括幾何(geometry)、位相(topology)和時間的演變(temporal evolution)。
(2)地理覆蓋(geographic coverage),包括幾何位置(geometry)和屬性值(attribute values)
(3)地理觀察(geographic observation),例如水文觀測,具有空間位置和時間動態資料的記錄。
(4)座標參考系統(Coordinate reference systems)。
(5)抽象值(abstract values),包括有測量單位的數值量化,和基於計算、分類和布林邏輯(Boolean)決定的觀測值。

GML的主要目的是提供一個一致性語言來描述地理物件,且透過這個方法所編碼地理空間資料可以輕易地分享在網路世界中。GML模式是基於物件導向技術(Object-Oriented)以直覺地建構真實世界的地理空間物件,因此GML的模式是由宣告地理物件和物件屬性所構成,Trninić (2005) 認為GML模式由幾個部份構成;首先是圖徵(feature),為基本地理物件,是來自於真實世界的抽象化,如道路或房屋;再者是幾何(geometry),是一種物件,而被用來描述地理物件的絕對位置,如點或多邊形;其次是位相(topology),也是一種物件,是用來描述地理物件的空間相互關係,如端點(node)或邊(edge);此外,地理物件也可以有許多屬性,如一個房子的具有多少房間是以表達,其「值」是一個整數型態和一個房子的空間屬性是以表達,其「值」是一個幾何座標的型態,如編碼表1。由此可見,每一個屬性有它自己的值,而值可能是一個簡單的型態,也可能是一個物件,因此GML模型是物件─屬性─值(object-property-value model),相對於ER(Entity-Relationship)模型,即為實體─關係─實體;或物件導向中物件─屬性─值模式(object-attributes-value)。

GML編碼技術是以XML Schema為基礎,是一個理想並適合於以分享為目的資料集。GML模式和它的核心綱目(core schemas)讓使用者可以描述所屬應用領用領域的地理實體,如同蓋房子前需要先畫好藍圖,這樣的藍圖不但得以在該應用領域被使用,一致性的表達方式,更使得這些地理資料亦可分享於其他應用領域中。GML核心綱目(core schemas)的元素是使用XML綱目(Schema)來構成GML的語義模式和語法規則,且GML是一個基於圖徵(feature)架構,因此一個地理物件通常可由一個或數個GML應用綱目(Application Schema)構成,如圖2所示,在GML名稱空間(namespace)中圖徵(feature)是由詮釋資料(Metadata)和幾何(Geometry)所組成,表示GML核心綱目中圖徵(feature)綱目 是由詮釋資料(Metadata)和幾何(Geometry)綱目所組成,而其它領域的名稱空間(namespace),如圖2的foo 1和foo 2應用領域中的schema 1、schema 2、schema 3所包含的元素(element),可以繼承GML架構中的物件,而根據各領域之專家對地理空間物件的模式,可建立以GML編碼模為基礎的應用綱目(application schema),而該應用綱目不但具有GML編碼規則與特性,同時又保有所屬領域中的對地理空間物件的闡釋,如此的物件可能包含道路、水溝、河流、建築物、山脈、崩塌地滑和斷層等各種的地理現象,而這些地理現象在GML中被稱為圖徵(feature),而這些圖徵在GML中是XML的元素(element),有明確的名稱(如)且藉由子屬性元素來描述,因此空間資訊將可利用GML當成一個交換標準以供各領域之專家來交換資料(Galdos Systems Inc., 2003)。

GML除了繼承XML的特色而有利於地理空間資料的交換,進一步地,剖析GML,可發現GML具有幾項特色,而被認為是解決資料相互操作性的重要基礎(Zhang等人,2003;鄧東波等人,2004):

(1) GML基於一個共通(common)的地理的抽象模型,而此模型描述真實世界中如何被一組圖徵(feature)所建構,地理圖徵是一個真實世界現象概括化物件,且該物件關連於地球上某一個空間位置,一個圖徵可有簡單的屬性和幾何屬性,簡單的屬性包括慣用的名稱、型態和值的描述,而幾何屬性可以是點、線和面所組成,因此由GML中的圖徵架構和屬性可使得圖徵容易整合,以及相互比較。

(2) GML所提供的核心綱目(core schemas),是一般性地理空間資料的描述方式,其中GML 3.1.1已增加至29個核心綱目,可滿足目前大部份地理空間資訊的編碼需求,因此藉由擴展與限制核心綱目,不但可充份表達多樣性地理空間資料,亦可使這些編碼遵循於同一標準。

(3)GML基於XML的標準,而在網路世界中對於結構化文件和資料,XML是一個通用的格式,XML是容易轉換的,除了可使用XSLT轉換外,幾乎其它的程式語言皆可轉換XML,因此依附在一個開放、非私有的標準,GML文件具有與XML同樣的彈性,可被運用、轉換和呈現。此外,現存的相關XML技術也同樣地可以應用在GML上,如XQuery和XPath的技術。

(4)GML相同於XML,提供XLink的機制,可連結不同分散的來源在一個複雜的關連(association),相同於,HTML被使用來連結網頁的重要地位,GML則被發展來連結地理網絡中地理空間圖徵集合,透過XLink可以將不同圖徵和圖徵集合之間作可跨文件的串連,因此XLink允許我們可以建構出複雜且分散的地理資料集,使我們可在不同部門間、縣市政府間,甚至國家間緊密地的整合資料及存取資料。

(5)GML文件可透過WFS在網路中相互傳輸資料,而透過其它的OGC所提供的標準網路地理資料服務,如WMS和WCS的建立與整合,不同格式的地理空間資料庫藉由GML格式以相互交換資料。

(6)GML資料完全以文字型態儲存,文字格式不被任何一個軟體可限定的,不同於現今許多地理空間資料格式是以二元制(binary)格式,使人無法閱讀,甚至解析。也因為GML是文字格式,它可以輕易的整合不同來源的非空間型態資料,如文字、一般圖形、動畫、聲音…等,這提高了地理空間資料的價值和親近性。

延伸閱讀:
2005年,國土資訊系統通訊,以地理標記語言建立異質地理資料之共享機制─以台北市政府為例
2005, GML Days, Vancouver, British Columbia, Canada, July 18th – 22thExperience in Building GML-based Interoperable Geo-spatial Systems
2006, Map Asia, Bangkok, Thailand, August 29th – September 1st Working with GML for Internet GIS: User Perspective and Experience

如何管理參考文獻

很多研究生一定會遇到一些看過的文獻,幾個月後,想找但找不到,下載一堆文獻,但不知道檔案在那裡,不然就是,在寫完文章後,花了很多時間在整理參考文獻。實事上,我也是遇到這樣的問題,做了一些功課了解如何有效率地管理文獻。

1.搜尋文獻
我們找文獻說起,網路日新月異,當碩士生時,查文獻只能上圖書圖的文獻索引光碟找,而且有人數限制,若是老師們”佔線”,你還得等到夜深人靜時候再用,相同的道理,如何你佔線,你可能會接到老闆的電話,叫你下線,因為他要用。現在時代不一樣了,SCI/ SSCI 索引己經整合在ISI Web of Science,搜尋條件也可以更加多元,幫助你容易找到所需文獻。拜Google超強的搜尋引擎所賜,上Google找也是一個不錯的選擇,但如果你的研究是比較通泛的,關鍵字一下,可能會有太多筆資料,就得相當花時間地過濾這些搜尋結果。CiteSeer是一個科學文獻電子圖書館和搜尋引擎,主要收集電腦和資訊科學的文章,個人還蠻喜歡這related document這個功能,這可以省去一些找文獻的時間。另外也可以透過社群軟體CiteULike來找,透過別人所下的標籤,可以找到你所想的文獻,而且你可以知道誰和你看一樣的文獻,想一樣的事。

2.收集文獻資訊
當找到這些文獻後,一則是下載這些文件的檔案,如PDF,另一則是需要把這些文獻資訊給整理起來。以前當然是剪下/貼上,然後在自己電腦上做編輯,這是舊方法,花時間!! 後來ISI Web of ScienceEndNote合作,可以將你在ISI上找的文章,直接匯入EndNote,實在太方便了! 但如果你的學校或工作單位沒錢買EndNote呢? Web 2.0時代,有許多新工具產出,也使得這些工作變得簡單。Zotero 即是一個自動辨識網頁中文獻,並收集到你的電腦中的一個 Firefox 擴充套件,如圖所示,當你瀏覽這篇文章所在的網頁時,Zotero 會自動辨識這是一篇文獻,並在瀏覽列上出現,收集這篇文章的小圖示,按了這個小圖示,這文章就直接收集到你的電腦,不用再一篇篇的作者、年代、篇名,期刊名….的整理,一個按鍵就解決,如圖的右下,且還可以按照分類和標籤來歸類,如圖左下。

3.管理文獻
除了收集文獻的資訊。另一方面也得下載文獻。通常我在文獻下載後,我更改檔名為這個樣子,年代_期刊_作者_篇名,使我容易找到文章。此外,我會將收集文獻資訊以BibTex格輸出到JabRef來管理,因為我用JabRef來連結PDF檔,這樣我找文獻時,就不用檔案搜尋,而是用JabRef來搜尋,更容易、省時、方便地找電腦中的文獻。