Gav's Blog

The issue of community-produced maps has reared its head on the IAEM email list today – closely linked to my post back on the 26th. The following issue was raised, and I wanted to share my reply to this.

Lack of citation was my major concern with the other available maps that have been in wide circulation. The second concern with the other maps is that they showed push-pins when they did not have or could not cite the data to support specific points.

My reply follows:

I think you’ll find that most of those maps do actually have references, in the case of the Google Maps mash-ups, they are contained in the hundreds of comments accessible from the same page as the maps. In fact, it is generally from the posting of these references in the comments, that the Google Maps get updated. What they have failed to to is to make it easier to reference the citations, by not including the reference in the popup bubble above the marker. But if you read through all the comments, you’ll likely find most of the citations there.

Another big failure is to create a timeline/history so that one can see the growth/change in numbers over time for each marker. Most of the maps are purely a snapshot of the here-and-now, and give no context via history.

The real point that emergency managers should take away from this is the following.

Agencies that ‘own’ the source information (e.g. CDC, WHO, and health agencies in every other country in this case), really should be publishing authoritative georeferenced data at the source. If agencies did this, then there would be no need for these ‘amateur’ cartographic efforts to hack together information from news, rumours and other sources. It would sure save a lot of time and effort in people trying to recreate information that already exists and either hasn’t been released, or has not been converted to a georeferenced format.

Likewise, it isn’t really the role of companies to provide this information. Once again, they are just filling a gap that we, as emergency managers, have failed to meet.

The mashup culture is a direct result of a failure by emergency managers to make information available in a form that end users clearly want it (as evidenced by the time and effort they will put into recreating the data in the form that they want to use it).

Perhaps we really should start thinking seriously about how we can produce authoritative information in formats that our communities want.

If you have a look at the example map I created in under an hour on the 26th, you’ll note that I created a little table in each popup for a marker that contained a link to the source article, and in the case of the San Diego marker, included daily figures for three days so it was possible to track the state of that marker over time.In addition, I scaled the marker images so that they were more proportional to the number of cases – a marker for each infection quickly produced an unreadable map, hence it seemed a better approach is to produce summary markers for each location, with the size of the marker indicating the numbers.

The real trick is going to be to produce a web application to track and manage this information, that can then export it in a suitable form to display the information as discussed above. This is clearly something we should look at for Sahana.

Well, it has been a lot of work for the admins, the mentors, and the students, but it has paid off. The Sahana has been awarded 10 projects in the 2009 Summer of Code. We have some great projects lined up! The include:

• Person Registry for Sahana
• Warehouse Management
• Disaster Victim Identification
• J2ME clients for form data collection in the field
• Optical Character Recognition for scanning forms
• Peer to peer synchronisation of Sahana servers
• CAP Aggregation and Firefox CAP plugin
• CAP Editing and Publishing
• Mashup/Aggregation Dashboard
• Theme Manager

Having been neck deep in the process; working with others to set up our assessment process, coming up with ideas (I’m stoked to have two students working on CAP ideas that came out of my earlier suggestion), and reviewing each and every of the 45 proposals we recieved, it has been exciting to get so many projects accepted.

I think that by the end of the year, we are going to have some great new functionality available in Sahana. Even more, I hope we’ll attract more open source developers to our ever growing community!

I’ve just uploaded the presentation I gave on Sahana at the Sahana 2009 Conference in Colombo, Sri Lanka on the 25th of March, 2009. I’ll put a link up to the associated paper soon as well.

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.

I haven’t blogged about Sahana for a long time, and I’ve got plenty to write. So much that I can’t decide where to start, so I’m going to pick a nice small piece to start with.

The Concept

Last year, I was involved in a project in New Zealand to produce an investigative report on Public Alerting Systems with the New Zealand Centre for Advanced Engineering. This report will hopefully soon go public, and I’ll provide a link when it does.

This report was looking at the different technological solutions for getting alerts out to people in as timely a manner as possible. At one point in the search for different systems, we started discussing means of injecting HTML in web pages via an ISP, so that a public alert could be sent out to anyone on the Internet. I’ll talk about this and other options later. Let me get to the point of this post.

After starting at the HTML injection idea, and progressing through a few others, I reached a kind of natural conclusion that a more suitable means of alerting users via a web browser would be a browser plugin that can subscribe to Common Alerting Protocol (CAP) feeds, and when a relevant alert comes in via CAP, this is displayed to the user in their browser using the XUL:notificationbox at the top of the webpage.

Draft Requirements

Anyway, a possible idea for a Google Summer of Code 2009 project is that of constructing a browser plugin for Firefox that implements this alerting capability, and expanding Sahana to support full publishing of CAP alerts. Here are some features it could/should support.

Firefox Plugin

• Bundle publicly available CAP feeds (ideally listed in a nice Country/State taxonomy – this will make it easy to discover and utilise existing CAP services.
• Allow users to optionally register location in some manner, so as the plugin can identify relevant alerts (by location) and give them higher status than say remote alerts. Users should be able to register multiple locations – whether it has home & work, or multiple cities. Privacy is of course king and this information must be protected.
• Provide a means of adding additional user provided CAP feeds to the plugin.
• Provide the ability to open the alert in a new tab and format in a human-readable manner, including niceties such as embedding Google Maps to show geospatial information and links back to the source website of the alert for verification.
• Implement means of verifying messages that are digital signed, and decrypting encrypted messages.

Sahana

• Implement a CAP feed in Sahana so that Sahana can act as both a producer (in terms of creating a CAP message) and a publisher (in terms of making it available via a CAP RSS/Atom feed).
• Implement a CAP proxy or similar, so that say all users of a Sahana server can obtain CAP alerts directly from the Sahana server – rather than going to an external website. This may be useful for distribution of alerts within an organisation or centre without having every client browser connecting to an external server.

What would be very nice, but may be beyond the capabilities of Sahana servers currently, is making the CAP service on a Sahana server easily discoverable on a LAN via zero-conf services such as Bonjour.

Draft Outcomes for Assessment

The outcome of such a project would be to produce a working solution whereby a Firefox Browser plugin is capable of working with public CAP alerts and that CAP within Sahana is capable of fully acting as a CAP server via RSS/Atom feeds to the CAP alerting plugin.

Compulsory

• Implement the specified requirements
• The browser plugin works as expected with publicly available CAP feeds.
• The browser plugin works as expected against the Sahana demo server. (Yes, this means that your modifications to CAP on SahanaPHP need to be implemented).

Optional

• Implement the Sahana CAP server in SahanaPY
• Provide one or more standalone CAP clients for a mobile platform e.g. Google Android, Apple iPhone/iPod Touch etc
• Write an Internet Explorer plugin with similar functionality – it is important that this functionality is also provided for IE given its widespread usage and deployment.

Whilst the plug-in can and should operate completely independently of Sahana, it should also be designed to work well with Sahana servers (e.g. SahanaPHP and SahanaPY).

Anyway, this is just an idea I wanted to float and get out in the community for discussion. I’d welcome any further comment or ideas to build upon this!

This time it is BusinessWeek promoting the “Do-Good Imperative” – including free and open source software. There is also a sister article on collaborative map-making during emergencies using the likes of OpenStreetMap. Naturally, this is an area that we are working hard on building these geospatial capabilities into Sahana as well.

Open source and collaborative approachs are certainly starting to get the mainstream attention that they deserve. Now we just need funding to support these developments.

Yes, it is an opinion article, but it is good to see coverage of Sahana in the Wall Street Journal.

A team of IBM developers customized and translated Sahana software, a free, open-source disaster-management system, into simplified Chinese to coordinate relief efforts in Chengdu.

The recent announcement of the second generation iPhone has a large number of people buzzing. The inclusion of Global Positioning System (GPS) capabilities into the phone creates a very capable mobile computing platform that has a lot of potential for emergency management.

What features make it a potentially useful tool for emergency managers?

1. Large storage – 8-16GB. Plenty of room for photos, documents and other material in a slim and very portable device.
2. Excellent user interface. I’ve been using an iPod Touch (iPhone less the phone) for 9 months now and have to say it is the nicest user interface I’ve used yet on a small device. I find it truly painful to use my Treo 750v mobile phone in comparison.
3. Multi-method positioning. The upcoming iPhone will be able to use three different methods to locate the devices current position. First, and most accurately it will use the GPS. It will then fall back to wifi, listening for nearby wireless devices and looking these up from a georeferenced database over the Internet, If both of these fail, then the least accurate method of using the cell towers will be used.
4. Multi-channel communication. The device will not only be able to connect via mobile carriers, but it the previous version it has wifi – at the minimum it could be used to connect to a local wireless LAN and access a Sahana server disconnected from the Internet.

Sure, there are some negatives too – it is a fragile device not necessarily suited to hazardous environments, and it doesn’t have replaceable batteries. Everything has limitations though and if these are recognised and accommodated, one could still achieve benefits from its usage.

Apple has also released a Software Development Kit (SDK) and infrastructure to allow software developers to write applications to run on the iPhone. This creates opportunities for development of tools that can be deployed for emergency management on an iPhone.

One example – as the iPhone has a GPS, camera, and means of connecting to the Internet (wifi or mobile) – it wouldn’t be too hard to write an application that could be made available for free download to citizen’s iPhones. Then, anytime they see say damage on the streets surrounding their home or work, they could take a photo, fill out some quick optional comments on a form, and submit the georeferenced photo and comments over the Internet to a Sahana server and instantly have the image geolocated for the emergency managers use. And, if the phone can’t make a connection due to failure or congestion, then the images are queued for delivery once communications are restored.

However, recent news of the iPhone SDK suggests that such an application would be in breach of the license agreement. I’m not a developer, but Electronista provides the following text from the license agreement, Section 3.3.7

applications may not be designed or marketed for real time route guidance; automatic or autonomous control of vehicles, aircraft, or other mechanical devices; dispatch or fleet management; or emergency or life-saving purposes.

I don’t have a problem with most of these – but the broad definition of emergency may stop deployment of emergency management applications on the iPhone. This is understandable from a liability perspective, but I hope it doesn’t stop developers creating ground-breaking emergency management applications using the potential of the iPhone.

Speaking of which, location-aware applications for the iPhone2 are already being displayed. Two very interesting ones to pop up so far are Loopt and OmniFocus. Very cool possibilites are opening up. Loopt is a location-aware social networking tool that lets you see if any of your friends are nearby so you can hook up for a meal or coffee. OmniFocus for the iPhone introduces location aware task lists. Near the office? Your office tasks pop up. Need to go to the grocery store to get item on your grocery list? It will provide directions.

It is going to be an exciting time for location-based services!

I’ve just heard some good news that Sahana is going to be deployed in Chengdu following the recent earthquake in China. This is excellent news!

Within two days, together with the project team at China System Center in Beijing, they have finished the customization of Sahana software based on the center’s specific request, and the People Module of the solution is ready to be deployed and start to function very soon. I know the team leader of the Chengdu Sahana Project team had just lost his house in the earthquake, however, he is fully engaged in the project these days.

I am very pleased to share with you that the Chengdu Municipal Government has officially accepted our proposal of using Sahana System to enhance their efficiency of the relief work! When Sahana System being deployed, and will be very soon, we will help over 100,000 people in Chengdu City and its 20 administrated districts immediately.

I hope that someday we will actually be able to get more organisations to not only deploy Sahana before a disaster occurs, but also to contribute to its ongoing development and improvement.

Dennis McDonald has again posted a thoughtful article on the application of social networking technologies for disaster response, and invited me to comment on it.

There are a couple of introductory comments I’d like to make before I respond in detail to his article.

The adoption of social networking tools for disaster response appears to be part of a larger movement away from the way information is traditional managed by those responsible for managing disasters. We have already seen this in the geospatial realm where government agencies do not appear to be providing enough geospatial information during a disaster, so we have watched a proliferation of mapping mashups to fulfil the needs that are not currently being met.

The simple fact that many people are choosing more modern tools suggests that the current solutions being provided by those tasked with managing disasters are not working. There appears to be a disconnect between the traditional approach of releasing press releases and situation reports, and the increasing usage of social networking and similar tools by the impacted communities. Emergency managers face a very real threat of being usurped by a collaborative network of individuals that are providing far more up-to-date and accurate information than may be available from official channels. This itself does carry some risk that I will detail later.
Read the rest of this entry »