We concluded our experiments on Thursday, November 19, after 10+ days on the ground.  The list of accomplishments we had at Camp Roberts as part of the RELIEF experiments sponsored by the Naval Postgraduate School is lengthy and a bit overwhelming.  We have plans to write up a much more formal report on the experiments - as well as a joint paper to be submitted to ISCRAM, so there will be lots more information available soon.

Here’s a (not-so) brief list of our accomplishments from the past two weeks:

• We used the Organization Registry and Volunteer Management System to track all of the persons and organizations and experiments taking place at RELIEF 10-1. This was a valuable demonstration of capabilities that sparked interest amongst several NGOs and government observers.
• We used a $400 (two years ago price) eeePC/Netbook as our primary data collection server as a proof of concept of the low barriers to entry of Sahana. (We did run the sms gateway on a windows machine as we didn’t have a data cable for our cellphone that had linux drivers (long story)). We got a lot of mileage from this.
• We configured Sahana OpenLayers to pull in WMS layers from mosaiced and geo-referenced UAV and satellite imagery of the Camp Roberts experiment site (minor tasks that we didn’t get to last August).
• We had a lot of discussions about using open standards for data exchange with government and non-governmental participants. We see Sahana as being a leader in this area.
• We had the opportunity to brief FEMA Administrator Craig Fugate on Sahana and the benefits of open source / open standards in the humanitarian/disaster response application field during a conference call with technology companies from Silicon Valley
• We configured an SMS gateway running on a Windows-based server using Cygwin and SMSTools and a Nokia 3220 phone to send and receive SMS messages from Sahana.
• We developed an Android application to send in structured SMS messages to Sahana with embedded GPS coordinates. We also developed the format for a structured SMS message to be sent from any cell phone to Sahana.
• We developed a system to register a user name to a cellphone number.
• These inbound messages (from Android app and simple cellphone) are now processed by Sahana to plot points on the situation map using the DHS symbolset of incident information based on feature class reported by the Android and SMS message.
• We utilized a lot of DHS and NIMS/ICS terminology throughout the experiments to demonstrate to a US-audience how easily Sahana can be configured to be “NIMS-compliant”. This will eliminate an important barrier to entry for US government entities at all levels of government. As part of this, we have blueprinted the requirements to have Sahana automatically generate one of the ICS forms that first responders are required to fill out
• The SMS capabilities gives Sahana the ability to serve as an incredibly powerful crowdsourcing and assessment application (akin to Ushahidi, Geochat and others of this ilk), and combined with Sahana’s native disaster management capabilities, truly gives Sahana users a more powerful situational awareness tool.
• We developed the ability to poll the Sahana server and pull information about the last known location of a registered Sahana user, the last report(s) sent in by any Sahana user, or a keyword search of all points of information plotted on the situation map. In the future, we’ll want to develop more powerful means to pull data onto handheld devices…. both through SMS and where the Sahana server can be accessed directly by an app.
• We created a KML feed from Sahana data such that we could call it up in Google Earth. This is very attractive to a lot of potential users who use google earth to aggregate data from different feeds.
• We participated in an integrated field experiment with observers sending in reports via SMS and Android back to a command center that was utilizing all of these capabilities to get situational awareness of an event. Sahana, of course, outperformed a lot of other systems that had had a lot more financial resources put into them.

Outside of all these details - and I’m sure I am forgetting a bunch - the bottom line is that we did something - every day - that impressed the heck out of the people there - and it was without exception something that we did not have the capabilities to do the day before.

We also utilized Launchpad with bazaar and set up a team on LP and a development branch with bzr that we plan to push back up and merge with the trunk over the next couple of weeks.  This worked great.  We found Launchpad to have a lot of tools for developers that SF is lacking - and made our work with remote support much easier.

I must recognize our onsite team - particularly Chamindra de Silva and Gavin Treadgold - who were there with me for over 12 days in California.  David Bitner was with us in person for four days contributing invaluable GIS and open standards expertise and advocacy to the team - and continued to support us remotely after he left.  Trishan de Lanerolle and Chris Fei from the Trinity College H-FOSS project were with us for four days working on the Android App and the VMS system and any other thing that we asked of them.  Dan Zubey also was with us for about 2.5 days and helped with server administration and configuration.  Remotely, we could not have accomplished much without the virtual support of Antonio Alcorn from Trinity College’s H-FOSS project, who worked on the VMS, Ravith Botejue, who fixed many bugs for us, Ajay Kumar, who helped us get up to speed on Launchpad and bzr, and Fran Boon, who helped with LP administration and advised us how to set up the projects and team and branches correctly the first.

Getting things done the right way was important to us, and we hope that we’ve created a replicable model for future events.

We welcome community involvement in our Sahana-Relief-Team, which we’ll stand up again before the next RELIEF event in February 2010 in Monterey, CA.  You can find the project page for the Sahana Camp Roberts development work at https://launchpad.net/sahana-relief-experiments and join the Sahana-Relief-Team at https://launchpad.net/~sahana-relief-team.

There is a brief that I put together highlighting the recent accomplishments of Sahana at the RELIEF experiments.  It is accessible here on my Slideshare site.

I wanted to give you all a quick update on the first two days activities at the RELIEF experiments at Camp Roberts in California.

Our team (Chamindra de Silva, Gavin Treadgold, Trishan de Lanerolle, Chris Fei and myself) arrived without incident at SFO on Monday afternoon and we all drove down together to Paso Robles in time for dinner with John Crowley representing National Defense University and the StarTides project, and Robert Kirkpatrick representing the Open Mobile Consortium.

On Tuesday, we worked on setting up our base infrastructure and began configuring the server.  Chamindra proposed using his eeePC netbook as the main server for the experiments - thus demonstrating an ultra-light, inexpensive deployment platform.  After finding Sourceforge unresponsive and completely unusable, we decided to set up a bzr branch on Launchpad for the code we would be using - pulled from the main Sahana trunk.  This enabled remote support from code contributors (such as Antonio Alcorn from Trinity College, who is already working on the VMS code and hopefully others) to be pushed automatically down to the eeePC server.  By the end of the day, we had this working.

On Wednesday, Gavin and I began in earnest to configure Sahana (locations, organizations, volunteer management system) with the assistance of some Naval Postgraduate School staff to be ready for the Monterey county exercise that begins on Friday.  We’ve spent a lot of time discussing how we make Sahana more NIMS/ICS compliant; we’ve set up organization services as the Emergency Support Functions (see http://tinyurl.com/yznwk4z) under the U.S. National Response Plan, and plan on using some ICS and NIMS symbology on the situation awareness maps.  Chamindra and Trishan are currently working feverishly on configuring the SMS/messaging system with a Bluetooth connected Palm Treo phone.  Ajay Kumar provided invaluable remote support on this.  Chris is working on getting Sahana onto the Android platform.

We have now set up a Sahana-Camp-Roberts subproject under the main Sahana project on Launchpad - that hosts a mirror of the main trunk code from Sourceforge as well as the code repository for the SahanaPy project.  Thanks to Fran Boon and Ajay for providing remote advice on how to set this up.  You can visit the Sahana-Camp-Roberts project page at http://tinyurl.com/ya3wzyj.  We do need help fixing bugs and making some feature request changes - if you are able to contribute remotely, please join the Sahana-Camp-Roberts team at http://tinyurl.com/ygecfpy.  We are working against this branch of code, and plan to push up all fixes and enhancements to the main trunk patches are developed once the experiment is over.  We are going to be putting feature change requests under blueprints - so please also check there for things to do.

Most of us are also actively using the #sahana chat room to collaborate with others - you can look for us there.

David Bitner arrives this afternoon and we will then be taking on a number of GIS-related experiments.  Dan Zubey comes in this evening to pitch in, and Brent Woodworth arrives tomorrow for a couple of days.

No kit foxes have been harmed by these events.

In an attempt to make a reusable component for form handling in Logistics, that supports validation and performs form processing automatically, I went through a few difficulties that are prevailing in the current libraries.

The form library does not use a common interface,

eg. lib_form.inc

function shn_form_button($name, $button_opts = null, $extra_opts = null)
function shn_form_text($label, $name, $text_opts = null, $extra_opts = null )
function shn_form_hidden($hidden_vars)
function shn_form_checkbox($label, $name, $text_opts = null, $extra_opts = null)
function shn_form_select($options,$label, $name,$select_opts = “”, $extra_opts = null)
function shn_form_radio($options, $label, $name, $select_opts = “”, $extra_opts = null)
function shn_form_radio2($options, $label, $name, $checked, $extra_opts = null)
function shn_form_multi_select($name,$options, $label, $select_opts = “”, $extra_opts = null)
function shn_form_opt_checkbox($opt_field,$extra_opts=null)
function shn_form_textarea($label, $name, $text_opts=null, $extra_opts = null)
function shn_form_upload($label, $name, $extra_opts = null)
function shn_form_label($label, $caption, $extra_opts = null)
function shn_form_password($label, $name, $text_opts = null, $extra_opts = null)
function shn_form_date($label, $name, $extra_opts=null)

The function signatures are different in even the same kind of form elements. Since the form elements do not have a common interface, it is hard to use these functions in a generalized way.

I feel that a better approach would be something like in the Zend Framework. The form elements in Zend framework are as below.

class Zend_Form_Element_Button extends Zend_Form_Element_Submit
class Zend_Form_Element_Reset extends Zend_Form_Element_Submit

class Zend_Form_Element_Checkbox extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Captcha extends Zend_Form_Element_Xhtml
class Zend_Form_Element_File extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Hash extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Hidden extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Image extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Text extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Textarea extends Zend_Form_Element_Xhtml
class Zend_Form_Element_Password extends Zend_Form_Element_Xhtml

class Zend_Form_Element_Multiselect extends Zend_Form_Element_Select
class Zend_Form_Element_Select extends Zend_Form_Element_Multi

class Zend_Form_Element_Radio extends Zend_Form_Element_Multi
class Zend_Form_Element_MultiCheckbox extends Zend_Form_Element_Multi

class Zend_Form_Element_Submit extends Zend_Form_Element_Xhtml

abstract class Zend_Form_Element_Multi extends Zend_Form_Element_Xhtml

abstract class Zend_Form_Element_Xhtml extends Zend_Form_Element

They all inherit from the same type, therefore having a common interface.

Zend is a Object Oriented framework whereas Sahana is procedural, therefore it might be hard to enforce the use of a common interface for the same kind of elements in Sahana libraries

Interesting concept from the World Food Program who looks to use micro-blogging as a major means of information transfer - CipCip, inspired by Twitter, is a micro-blogging platform for humanitarian relief operations. According to the WFP Deliver project, which focuses on the delivery of information:

“Please welcome CipCip (pronounce “TJEEP-TJEEP”, Italian for Twitter) to the DELIVER family”

So how does this differ from Twitter? This statement sheds some light:

“CipCip, is like Twitter, but internal to our organisation. Access is restricted, and new users are added by invite-only at this time.”

And it focuses solely on humanitarian relief messages etc. Restricts the message getting out to the masses, like what Twitter does, and rather makes sure the message stays within the organization - seems to be Twitter with user permissions. And it is being used, according to WFP:

“Already we have had our first user ‘Ciping’ from Maputo, Mozambique. We have live streamed meetings so that we could remain working our desks while one of our team ‘Cip’d’ updates.“

Yet another innovation for the humanitarian domain.

Before jetting off the Colombo this weekend for the first annual Sahana software for disaster management conference, I want to provide an update on the input and ideas collected for the Sahana 1.0 release. I am personally a bit behind schedule myself on managing this, and for that I apologize.

However, I would like as much as possible to try to keep to the schedule I posted on the wiki which allows through the end of April to make a technical and strategic plan for what’s going into the release and what’s not. So, I would welcome any additional suggestions and thoughts as to what should be included in the 1.0 release. Please continue to send them in to the sahana-user or sahana-maindev mailing lists. I have a feeling some other ideas and discussions on this may take place in Colombo next week, so I will keep the list open through next week. This is definitely on my personal agenda to discuss at the BarCamp.

Anyway, here’s the list of ideas – most are new and some are adjustments to others already noted in some form on the wiki already:

- Merging of bug-fixes and enhancements from China / Sichuan deployment (for 1.0)

- Staff deployment and other enhancements from NYC deployment (for 1.1+)

- Make an RC branch off of trunk past 0.6.2.2 branch to capture many enhancements made for the 1.0 release – let release team work on it to capture bug fixes for trunk from other branches.

- Review list of bug fixes required for proposed 1.0 branch and trunk, and update tracker accordingly, such that experimental development can continue towards features planned for 1.1+ releases (currently noted as 0.7 and 0.8 on the wiki – plus GSOC 2009 projects).

- Windows and other supported OS installers to include as much auto configuration as possible and easy to follow prompts where user input is needed to set-up Sahana

- Document the installation package creation process on the wiki such that future release teams can follow it.

- Complete third party library review

- include the LGPL license text in the base directory of the package

I think that was it. Let me know if you think I missed anything; and please do feel free to send additional suggestions through next week.

Sahana has been again selected to participate in the Google Summer of Code (GSoC) for 2009.

A full timeline of important dates for this summer is available.

We were selected as 1 of 150 out of about 400 groups who applied this year.  This is a strong testament to the reputation that Sahana has built up of the last few years and the great success that we have had as part of this program previously.  We still do not know how many students we will be able to involve this year, but it may likely be fewer than we have had in the past as there are fewer spots to go around.  Further information about student allocation can be found here: http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations.

Students:
If you are a student who is interested in participating in the GSoC this year, I would encourage you to review our ideas page and our student guidelines on the Sahana Wiki.  Once you have reviewed that information, I would invite you to discuss any ideas that you may have on the Sahana maindev mailing list or via IRC .  Students who take the opportunity to discuss their ideas with the Sahana development team will definitely have an easier time pulling together quality proposals.

Here’s another CAP idea I wanted to get out before I read a document I’ve been sent that may cover the same topic (just to make sure I don’t potentially draw on someone else’s idea). This concept came to me, again, last year whilst I was working on the CAENZ Public Alerting research report last year (I’m still waiting for this to be publicly released so I can link to it). My recent post proposing a browser plugin for CAP alerts is part of this bigger picture I am outlining today.

The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts - whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points - a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.

Originally posted on my blog, republished to TalkSahana.