Santiago, also known as Palla, is a highly pragmatic dev lead, perfectionist and efficient, motivated mostly by back-end challenges. In Computer Science at UBA, he is known for being a hard TA to his numerical methods students. His preferred topic, and the subject of his master thesis, is linear programming and operations research.
One of the issues that arose during the integration process was how to maintain user identity when integrating between different systems. During the exercise, data was moved around anonymously, without having more than a display name describing an item’s author; but for real world behaviour this is unacceptable.
Therefore one of the many points (I cannot emphasize enough the word many here) that were left for work after the exercise was researching on a way to seamlessly allow users to use the different applications without requiring a long and tedious process. During a crisis, there is no time to get an account on three or four different systems and after that, configure them so each knows what your username is on the other ones.
Nevertheless, the possibility of using a standard such as OAuth for sharing data for those users already on the userbase of all systems is not discarded. For cases when users have been using one or many of the systems, allowing them to get an authorization token on one application to grant usage for another one, is a great feature to be implemented. It is also a common standard so whenever any other application wants to join the mashup, it should be as easy as possible.
Another option that came up was using a common user base for all systems, such as OpenID. This way a user would only have to create an account on a single server (any open id provider of choice) and use that ID to login at any of the servers, therefore the identity of a user is shared along all systems without requiring any configuration.
The main drawback of this last option is that it requires access to the OpenID provider, something that is not always available on disaster scenarios. Among the features that were considered important to react during a crisis were both portability and the ability to work offline, both out of the network and within an internal network disconnected from the Internet. Using a user base on the cloud would not benefit this goal at all.
Therefore one of the tasks for these weeks is envisioning a robust standard login method for all applications that allows integration among systems as seamless as possible. User startup time during a crisis must be reduced as much as possible, while still retaining all the security features necessary to maintain the required standards to protect user’s privacy.
This past week at Camp Roberts has been incredible. All of the groups present did an amazing work, and we got to test InSTEDD’s GeoChat in a completely different scenario and integrate it with most of the other applications present to come up with a full cross-systems solution for distasters related scenarios.
First challenge was the actual deployment of GeoChat. Since we were looking forward to develop several mashups on the fly, we took with us a separate version of the server so we could tweak it as much as needed for the sake of the exercise without modifying the already running production server (which, by the way, you are all welcome to use). We would also be deploying a local gateway, which is nothing more than a simple client installed in a laptop connected to a cell phone that relays messages from and to the server, as the US shared gateway was in use at the production server. The huge problem was we did not get any signal on the base.
Fortunately, Brian and his people from HFN set up a Forward Operating Base on top of a hill which did get good cellphone coverage, and using WiMax antennas they managed to forward network access for us into the base. So we had a local instance of a GeoChat server up and running with its own local gateway.
Forward Operating Base
Among the organizations in the exercise was Google, with their mapping technologies. They made an amazing job processing a detailed set of imagery using a Google Earth Fusion Server (that nearly made the whole trailer we were in tremble when it was turned on) and providing all of the others parties with access to a Google Earth Enterprise server which served these tiles.
Google Earth Fusion Server
The processing of all of the available NGA imagery that was available took the server almost an entire night, but the results were truly spectacular (check the link, video included!). I regret not having a screenshot of the data actually displayed inside GeoChat, as the high level resolution yielded a great visualization.
The first ones to make excellent use of this imagery were the people from OpenStreetMap and Walking Papers. The former is a collaborative initiative for mapping, the latter consists in printing maps based on OSM and having them scanned back to generate input in the system. Within a few hours, they managed to generate transparent layers that, being overlaid on top of the GEE imagery, produced some awesome results: OSM data printed together with detailed images of all around the place.
Since these maps provided an excellent reference for the camp we were in, we decided to integrate them into GeoChat as a new geo reference system. Therefore, whenever a new walking paper was printed, a post was made to our server with the details of the map and an ID. After that, anyone could indicate their position using a simple grid reference printed on top of the map. By sending #map MAP1 GeoChat associated MAP1 to the current user as the current walking paper, and with grid A3 54 it was possible to make a location update in the system, without needing a GPS to get the latitude and longitude coordinates, as the translation was made automatically on the server. We will be looking forward to have these features and others migrated to the main code trunk as we polish them up for public use.
Sample walking paper with grid on top (image from Mikel)
As walking papers works by using a scanner to input annotations back into the OSM server, and we were on a disaster response scenario, we wanted GeoChat to serve as a channel to report alerts on real time that could be displayed on OSM, without needing for a user to go back to base and have his or her map scanned. Therefore we created a list of tags that would trigger a postback to OSM whenever a message containing any of them entered GeoChat:
minefield fire flood bridgeout bridgeup roadout roadup supplydrop riot looting kitfox hospital clinic aid sewage gasleak shelter fighting safezone pollingsite landslide outbreak government gov emergency camp ngo
Personally I have to thank Mikel for the huge help he gave us in making the integration possible. He also has an excellent recap of the event on four consecutive blog posts.
Sahana was also there with their disaster management system, looking forward to pull data from most systems. So we coded a quick GeoRSS feed for them to consume, and by the end of the exercise Sahana was showing GeoChat messages on map along with many other layers. The visualization worked great.
Sahana map visualization
The people from Development Seed focused on developing an elections monitoring system for Todd Huffman who was looking forward to test and use all of the toys we created during the week. Having the system pull imagery from the GEE server added even more value. More info on Eric’s blog.
We also got some great presentations by the people of TerraPan with their low cost UAVs, by Patrick Meier who represented Harvard’s humanitarian initiative, and many more.
Overall it was an excellent week, full of great people with great ideas only waiting to be implemented. The collaboration and integration produced during these few days was invaluable, and we all have a lot of work to set everything up for the next iteration of RELIEF.
(here is a link to my photo album and to Eric’s one with pictures of the event)
This week Star Tides, in partnership with the Naval Postgraduate School, will be organizing a Concept-based Experimentation (CBE) in Camp Roberts (CA). The objective is to to analyze the state of the art of current social and information related applications in the context of humanitarian emergency scenarios. Invited to the event are Development Seed, Sahana, Google and InSTEDD, among others.
As we at Manas have been working side by side with InSTEDD on the development of GeoChat and Riff, I got the chance to participate on this experiment toghether with Luke Beckman, InSTEDD’s National Response Liaison.
The agenda includes setting up servers of everything we may use for handling communications, information and imagery, simulating an emergency scenario in Camp Roberts. The most interesting part is what follows: integrating as many tools as possible, developing mashups on the fly to maximize the synergy of all applications.
The final goal is to be able to identify precisely where we all are, and what we should be working on during the next months to be prepared for rapid emergency response.
I have to thank Manas and InSTEDD for the opportunity to parcitipate on this event, and I will try to keep the blog as updated as possible with the news of the event.
