An interesting article I came across recently describes the use of Internet traffic counters to track “web hits” in order to determine earthquake locations, according to NewScientistTech. Thus based on the surge in ‘Hits’ for a certain geographic area per unit time, it can be determined to some extent that something has taken place in the region - in this case, an earthquake. The study is carried out based on usage statistics of European-Mediterranean Seismological Centre. Again, social networking to the rescue…

Ok - pretty outdated. But, as part of my pledge to get anything and everything on Sahana blogged, here goes.

Sahana was mentioned in this Open Letter to the community by MySQL founders: David Axmark and Michel Widenius

Some other awe-inspiring MySQL stats that show the momentum of MySQL:
Major free software projects and hugely-popular Web sites such as the Sahana (disaster recovery system for the tsunami), Ensembl.org and Human Genome Project (used for cancer research), Wikipedia, Bugzilla, Craigslist, Feedster, Flickr, Freshmeat, LiveJournal, Neopets, Slashdot, SugarCRM, Technorati, Wordpress, CERN’s ATLAS Experiment — all taking advantage of MySQL’s speed, ease of use, flexibility, scalability and ecosystem.

Source

Couple of months earlier I had a chance to install Sahana on a OLPC. After some initial search I realise the best solution would be to create an OS image with Sahana  because then the installation would be easy. There are two basic image types for olpc which are devel_ext3 for live USBs and devel_jffs2 for on-board nand flash.  I choose to create the live USB image sine it was easy to work with and most importantly I did not want to mess the existing system on the olpc I got, which is a machine brought here for demonstration.

To build custom images there is a package called pilgrim which contains a bunch of tools to help you out. You can specify which repositories you want to use and which packages you want to install on the image in pilgrims configuration file.  Then you run the pilgrim-autobuild command, and it will download the specified packages and build the image. The tool is capable of building both images in a single run. For more information on how to do this visit  http://wiki.laptop.org/go/Building_custom_images.

The pilgrim tool is bit time consuming ( this may be because the internet connection I used was bit slow ) so I decided to remaster an existing image. I downloaded the latest stable image from  olpc.download.redhat.com and mount it to a local directory. Then downloaded the necessary server packages from the fedora core 8 repository. Since the olpc is based on x86 architecture  packages build for i386 architecture will probably work. Next step was to chroot to the image directory and install the packages using rpm command. Aftter that I install and configure the sahana stable version on it. Now it is possible to unmount the image and flash it to a usb drive. Then plug the usb to an olpc and boot from it. To try out the image I build visit http://wiki.sahana.lk/doku.php?id=doc:olpcimg:english.

Sahana worked smoothly on the OLPC and the page load speed was very good too considering limited hardware resources. And the system was usable the only problem I found was the tiny key board which is bit hard to type. So it seems that Sahana can be used with an olpc to collect information in a disasters situation.

Multiple user groups,Industry and FOSS/GIS communities started an effort to develop/customize Sahana for the recent disaster in Myanmar (Cyclone Nargis). The whole effort started based on a three day (3-5 June) conference call and a user training held by some of the Sahana community members.

This Team (or rather group) consist of a number of locals/International volunteers, Humanitarians, and representatives of IBM US/Aus, InSTEDD,LSF, Respere and OpenStreetMap.

Team decided to do the customization based on the last stable release of Sahana (which is 0.6.2) and incorporate some of the important features (specially GIS functionality including TMS support for OpenStreetMap) from the unstable release. This will be a definite challenge for the developers to merge some of the bleeding edge code with relatively old code, while maintaining the stability on the whole application.

As an outcome of these discussions, there was a request from the team to have a separate CVS branch for this customization. Based on the CVS convention, I managed to find the time to create a new deployment branch for this, known as ‘dep_0_6_2_myanmar’. This branch can be obtained by anyone (as anonymous user) by issuing following,

cvs -z3 -d:pserver:anonymous@sahana.cvs.sourceforge.net:/cvsroot/sahana co -r dep_0_6_2_myanmar -P sahana-phase2



Sahana project perspective, this is going to be a major push for releasing another stable version of the application soon. The six month old current stable application needs another release.

Choice: an important thing, especially if you’re short of time and other valuable resources, especially during crisis situations. I mentioned sometime back that the goal of the SahanaGIS work was to allow existing GIS users, using existing technologies, to make use of the system without disrupting the flow:The GIS catalog is an important part of this..

The Sahana GIS catalog is an administrative module within Sahana that allows users to configure geographical data/feeds. It attempts to provide users with a somewhat intuitive interface to configure various layers, which in turn can be viewed by the Sahana GIS client which uses OpenLayers. Support for newer ‘types’ of layers/feeds are added frequently: our goal is to support quite a few of these in the near future.

At the time of writing, the following are configurable and thus usable from within Sahana: OpenStreetMap (both Mapnik and Osmarenderer), remote and local TMS layers, remote and local WMS layers, Commercial Mapping APIs: GoogleMaps, YahooMaps, Microsoft Virtual Earth, Multimap, and feeds: GeoRSS and KML. The files layer can be used to upload and use the following: KML, GML, OSM. WMS and TMS layers accept multiple layers within them. Layers can be enabled by the administrator so that they are visible within the OL mapping client by default. This works perfectly for data from custom mapping servers: either local or remote. Maps served as WMS via mapping servers such as UMN/Mapserver can be accessed by configuring the WMS layer in the GIS catalog. Likewise, tiles from TileCache and the likes can be accessed by configuring TMS to point to them. In turn, the configured layers are displayed within the mapping client, depending on their visibility settings. There are a lot of items on the roadmap as well: including WFS support… Check out the Sahana GIS Infrastructure Roadmap to see what we’re upto…

Google has released its revolutionary mapping client, Google Earth, for web-browsers, according to Google LatLong

Today, I’m happy to announce the release of the new Google Earth Browser Plug-in, which brings the full power of Google Earth to the web, embeddable within your own web site. Driven by an extensive JavaScript API, you can control the camera; create lines, markers, and polygons; import 3D models from the web and overlay them anywhere on the planet.

However, as is the case with many Google applications (including Google Earth for some time), us Linux users have to wait - again. The technology is currently available to Firefox 2 and Internet Explorer 6/7 on MS Windows only. However, I guess this move will create a lot of interest - Google Maps API certainly did - add 3D ability to that now, and imagine the possibilities !

We used Google Maps API within Sahana as the primary plugin for GIS. We now concentrate on having OpenLayers as the main mapping client, allowing a host of services to be accessed through it, including the GoogleMaps API. So once the Linux/Mac ports are done, I wonder if and when OpenLayers support for GE would be on the roadmap..

The video on the DisasterTech presentation by Mikel Maron and Jesse Robins at Where 2.0 is an interesting insight into Innovation in Disaster Response. Also interesting is the issues mentioned of getting geeky innovations into mainstream disaster-relief operations, or, as they say, making technology count. Absolutely true: but as Paul Currion mentions, this factor must and should be taken into mind as well: there are many technological events out there, but the dots should be connected. This I guess is true for many technologies, where the bigger players who have more visibility are more successful. I think Mikel’s comment on the need for a Champion for technological innovation stands true here - the need for someone to adapt the technology, which in turn brings a lot of visibility to it. Let me for instance take Sahana: since Sahana is being used widely in many disaster deployments, it in turn has paved the way for newer technology integrated into it to work in real-world scenarios.

It would be interesting to see how the newer features of Sahana, such as GIS, AJAXified custom reports, Webservices, SMS Messaging and the likes are used in future deployments, in real world scenarios. Crisis response is such that technology MUST work: and a lot of testing is needed to test out the practicality of these applications to make them ready for potential deployment usage. But that in turn brings us to the critical question: is there a line that should be drawn in terms of practicality vs. cutting-edge technology for disaster response technology? In my opinion, Sahana is well balanced now - its got the right mix of practical applications, along with innovative technological solutions: and there are newer , much needed features being built that are coming soon. But will Sahana become too technologically bloated some-day where technology might hinder deployment? Scary thought, but I guess that can be true, given the criticality of the domain.

Sourceforge Community award is back again. Nomination process will be finish by late June. Those who would like to nominate Sahana project for these awards (individuals can nominate a project for multiple awards) , can now click following button.

It’s clear that project like Sahana (which aligned to disaster management and humanitarian domain) needs more visibility, than normal FOSS projects. However, Sahana project has been recognized number of times in the past. Sourceforge project of the Month - 2006 and Social Benefit Award - 2006 by FSF, were significant.

Along with the recent surge in the Geographical Information System (GIS) development stuff of Sahana, I guess its high time I posted something on this:  The Sahana Disaster Management System’s geographical capability has been improving in recent times. The purpose of GIS development in Sahana (a.k.a SahanaGIS) is  not to create a fully functional GIS: there are enough and more brilliant solutions out there: rather, our focus is on allowing users to get the maximum geographical capabilty out of the system, by making use of existing systems and standards.

The SahanaGIS is built on a distributed architecture of small reusable components that serve each other. Each component is standard-compliant based on Open Standards, and makes use of existing F/OSS projects and services. This allows for standards based interoperability with existing systems, and existing F/OSS or proprietary GIS solutions can be used interchangeably with these components to achieve full GIS capability within Sahana through collaboration. At deployment, Sahana would probably contain a rich set of data regarding the disaster it is setup to manage: the ability to share this data integrated with spatial data of the region would mean a rich set of geographical data being served out to the GIS community in times of a disaster. This project also provides the ability to manage the Sahana data sources, feeds, files and mapping APIs via a GIS catalog module, allowing a wide variety of sources to be added and configured on the fly, which means that a fairly substantial GIS can be configured by someone with little or no experience of GIS.

SahanaGIS provides the flexibility for users to use tools of their preference: we do not intend to build a newer tool to replace existing tools that users are comfortable with. For instance, data served out of Sahana can be viewed using the inbuilt Sahana GIS client built uing OpenLayers. Alternatively, users can use the myriad of GIS clients out there: qGIS, uDig and the likes, to acheive the same. Similarly, mapping servers such as UMN/Mapserver can be setup to serve data to Sahana clients. Thus, Sahana can be used within existing GIS infrastructure, without distrupting the flow by requiring users to migrate to newer software: which is not practical during disasters, especially considering the level of expertise required in Geographical Science.
Well, that’s a start from me: definitely more stuff to come…

May 13, 2008, Colombo:
The Sahana Messaging and Alerting Module, which recently received a major face lift (well, more than a face lift: actually and overall lift ) courtesy of Respere, was presented at the LirneASIA colloquium for Disaster Management and Messaging. With an attentive audience, the colloquium was a success, and we managed to gather a lot of valuable feedback for the evolution of the module.

The Sahana Messaging and Alerting Module (acronym: SMAM) is a Sahana module that concentrates on sending messages to end users. There has been a lot of discussion on the Sahana lists and elsewhere regarding the efficiency of short/text messages during times of a disaster, and its ability to somewhat withstand the issue of messages not getting through due to network congestion problems during disasters: which is exactly why we concentrated on SMS as the primary mesaging medium for sending messages. However, having other media such as the implemented EMail functionality, and future implementations such as MMS and IM for messaging is important as well: in a period where messages reaching its recipients is doubtful, I guess duplicating the effort through various media might ensure that at least some messages get through.

I guess there are four defining characteristics of the SMAM.
1. Free/Open Source Software solution: The solution is F/OSS: thus with its transparency and large user development community, the module would definitely be improved and evolved by many developers. Even as we speak, there is a Google Summer of Code project to improve the module and build in newer features.

2. Tight integration with Sahana: The module is part of the Sahana Disaster Management System, which in turn means many benefits. Sahana consists of a large community consisting of end users, practitioners, developers, technical specialists, domain experts, researchers, academics and the like: all of whom could provide many valuable contributions to the module as a whole. Secondly, a live deployment of Sahana is bound to contain a rich dataset of valuable disaster related information. The SMAM can make use of this information in its operation: say, it has the ability to send out alerts to all people living within 100m of the coastline, making use of the People’s registries and GIS. Or possibly messages to all volunteers working in X and Y regions under Z sectors: the data being provided by the Organization Registry and the Volunteer Managment Module. Thus the possibilities are endless, and Sahana has the modules that could prove this to be a very useful aspect of an alerting system.

3. The solution is web based: is this good? Of course it is - this means that accessibility to the system is quite flexible: the system can be accessed over the Intranet or the Internet, depending on how you set it up: and consisting of the Sahana Access Control procedures, access can be controlled quite well. On the other hand, the system can be run as a standalone system as well: giving the best of both worlds

4. Finally, we built in a ‘plugin architecture’ for the messaging module. This, inspired the by the work done on the Sahana GIS stuff, allows the developer to plug in various plugins to achieve the required functionality. In the SMAM, the SMS Gateway is built in such a way: we’ve tested the system by plugging in Kannel and SMSTools as the SMS Gateways: this is quite useful, since both Kannel and SMSTools works in distinct ways and have their distinct advantages: which makes a lot sense depending on how the system is hosted, and what permissions the system has. A plugin architecture allows the developer to write interface code that will ensure that the gateway works with Sahana: and thus, any gateway can be plugged in.

More of this to come soon: I just gave a technical overview in this post.

Related Posts:
ICT4Peace - Sanjana Hathoduwa
LBO - Rohan Samarajeewa