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…

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.

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…

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