Sahana-Eden for Pakistan
The Sahana-Eden community has deployed their software to support the flood response in Pakistan. For more details, see:
S3 becomes “Sahana Eden”
The SahanaPy project (internal codename: S3) has finally got a name:
Sahana Eden
EDEN can stand for “Emergency and Development ENvironment”, but actually there is no official interpretation yet.
The new official URL, however, is:
Another challenge
SahanaPy is being used as development platform in another project: a portal site to track and manage requests for food aid between the aid organisations involved in the Haiti relief effort and the UN World Food Programme.
The wider the scope grows, and the more practical experience is flowing in, the more limitations and wrong assumptions come to the fore. While the REST-heart seems to be strong and keep most of promises (not all, though), the UI - especially those features mainly based AJAX technology - turns out to be a rich source of problems (~50 to 70% of all issues). As a main reason for the latter I understand the loose implementation of indivual solutions with insufficient framework integration instead of solid generic formulations.
However: another challenge - another small step ahead.
Sahana HMS for Haiti
People think we have done something new: the Sahana Hospital Status Assessment and Request Management System aka HMS. Actually looks like a useful thing:
…I am on the ground in Port-au-Prince helping with the relief efforts. I met a physician at the UN who shared with me that a huge problem hospitals are having is coordinating transfers of patients. One hospital will not necessarily know the capabilities of another hospital, or how to contact the hospital, or—even more importantly—how many beds that hospital has available.
I mentioned that the Sahana hospital info system seems to be a great solution….
However, it is not new: the magic engine was already there. Build in months, created in painful detail work and nightlong discussions of just us two. The small rest now has been nothing but new labels for the same thing.
Though – we were not through yet and not at all prepared for deployment for Haiti. Honestly – the new engine was not ready to race yet, S3XRC is only half the way. Or maybe two-third, but however a stub. We could have completed that already, if we wouldn’t have to do that all in our spare time of which both of us don’t have enough. But funding ain’t.
However, now they grab at it as if it could extinguish fire – the Sahana people run around with flashing warning lights on their heads as if they could save lives with mouse clicks. But actually it is rather about helping Sahana to survive – while the people in Haiti are still suffering.
Please note: that was not my intention! I was creating that out of what we discussed in Kobe and Himeji – to help the health professionals – especially my colleagues – to do their really vital work. All else is just the picture frame, nothing but flies on the windscreen of fate, obfuscating the clear sight on vital information while people are in need – while children loose their arms and legs due to the lack of means for early proper surgery.
SahanaPy Haiti Response
The Sahana Software Foundation operates a SahanaPy instance at:
Services provided so far include:
- Capturing of information about Aid Organisations, their offices and their activities on-site
- Situation Mapping
- Request Management
If you think of volunteering for Sahana – welcome! – we have plenty of tasks for you, e.g.:
- Data collection and entry
- Documentation
- Translation (French, Haitian Creole)
- Code-writing
- Coordination of volunteers
- Communications
Join us on IRC:
International Forum on Disaster Nursing
I am currently in Kobe/Japan for a meeting on the International Forum of Disaster Nursing, presenting about our works in SahanaPy and the development cluster approach.
From the initial meetings, especially with Mrs. Janice Kishner (East Jefferson General Hospital, New Orleans), it is again clear that nurses are a leading force in emergency management, and there is a demand for tools like SahanaPy to better handle the situation, especially regarding:
- Logistics
- People Tracking and Tracing
- Human Resources Management
This confirms the priority list I already had for my SahanaPy works.
On the other hand, there’s still a huge need for localisation – and for better streamlining the development and project management in Sahana(Py) in general. There’s a lot of potential input, if we only take it up effectively and in time.
A portal supporting clusters from the foundation website would be very useful in this regard.
dict.cc
For a very long time now, I’m using dict.cc to write all my english texts – be it blog entries, wiki pages, presentations, code comments, instant messages or e-mails – whatever. Just to look up a word or to check a phrase, check my spelling, find alternate expressions…yes – I even use it to train my pronunciation before talks and presentations – using dict.cc’s audio representation feature for many words. Dict.cc has accompanied me in years, it has become somewhat a part of my personal infrastructure – and has definitly made me better talk to many people all around the globe.
I’m really delighted with dict.cc, which meanwhile has grown up to a top-featured, community-written online dictionary for German/English into multiple European languages. It’s outstanding availability, performance and it’s usablity with such invaluable features like phrase search, synonym search, audio representation and more make it one of the most useful web sites I have ever seen. And it’s QA mechanisms make it one of the most trustable translation resources on the web.
And as priceless as it is – it’s free!
Thousand thanks to Paul Hemetsberger and all the contributors!
Keep up the good work!
In re: Interoperability
David W. Bitner promptly added XSLT templates for KML and GeoRSS:
“This will be sooooo awesome for being able to quickly extend to read/write any format”
“Nice thing about this architecture is it allows someone like me to come in and add new formats without having to understand *any* of the code going on”
Interoperability
I actually like that built-in GPS of my NOKIA 6220 classic cellphone. This is not a highly advanced professional equipment though, and I’m just using it to map the landmarks of my daily travel – for no serious reason, but just for fun.
However, here is what makes it a Sahana equipment:
The landmarks collection saved in the cellphone can be exported in a very comprehensible XML format, and shared via SMS, E-Mail or Bluetooth.
The XML interface of the SahanaPy RESTful API uses in-line XSLT transformation for export and import of data, so I thought it would perhaps be cool to have a template to import the landmark positions from my cellphone as GIS locations in SahanaPy.
So I added the following XSLT template as “lmx.xsl” to sahana/static/xslt/import:
<?xml version="1.0"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
xmlns:lm="http://www.nokia.com/schemas/location/landmarks/1/0">
<xsl:output method="xml"/>
<xsl:template match="/">
<sahanapy>
<xsl:apply-templates select=".//lm:landmark"/>
</sahanapy>
</xsl:template>
<xsl:template match="lm:landmark">
<resource name="gis_location">
<data field="gis_feature_type" value="1">Point</data>
<xsl:apply-templates select="./lm:name"/>
<xsl:apply-templates select="./lm:coordinates"/>
</resource>
</xsl:template>
<xsl:template match="lm:name">
<data field="name">
<xsl:value-of select="./text()"/>
</data>
</xsl:template>
<xsl:template match="lm:coordinates">
<data field="lat">
<xsl:value-of select="./lm:latitude/text()"/>
</data>
<data field="lon">
<xsl:value-of select="./lm:longitude/text()"/>
</data>
</xsl:template>
</xsl:stylesheet>
Then, I added “lmx” to the supported XML import formats of 01_RESTlike_controller.py:
shn_xml_import_formats = ["xml", "lmx"] #: Supported XML import formats
After that, I sent the landmarks file from my phone (via bluetooth) to my server and import it just by calling the following URL:
http://localhost:8000/sahana/gis/location/create.lmx?filename=/home/dominic/landmarks.lmx
Done! Now I can use my “landmarks” to track people and shelters and other things, view them on maps, link other resources…
Finally, I added another template to be able to export SahanaPy GIS locations as NOKIA landmarks in order to import them on my cellphone, and that works equally good, just exporting by calling:
http://localhost:8000/sahana/gis/location.lmx
and sending the exported file via bluetooth to the phone – it immediately audibly indicates a new message – and when you choose “View” for that message then you get a list of locations which you can easily view on map or load into the navigation system.
Cool.
This is the first implemented cross-platform interoperability feature in SahanaPy, based merely on the SahanaPy RESTful API!
Missing? Persons Registry
Some thoughts about maintaining “Missing Person” registries in disasters:
Sahana maintains a list of missing persons, and therein treats “missing” as attribute of a person entity, meaning, a missing report always creates or updates a person entry with status “missing” and additional information to support the search, while finding that person updates their record as “found”. That’s the usual way of maintaining missing person lists, but I feel this is wrong:
First of all – there is no such thing like a “missing person” – instead there are:
- Persons
- Reports that someone is missing a person (missing report)
- Reports that someone has found a person (find report)
Sounds the same? It isn’t!
“Missing” and “Found” are presence conditions that are completely independent, and can even co-exist. A person can be missing by their family, while being very present to aid personnel or the medical examiner at the same time. Or there may be persons that are actually “found”, but not reported “missing” – however, the question is – can the “found” person be identified?
If yes – then you simply update the person’s presence log and thus inform the database (and other users) where the person actually is. Let’s therefore assume that – like in VITA – for every found person – whether identified or not – there is a presence log in the database which documents where the person currently is and under which condition.
Let’s assume further, that missing reports are filed on identified persons only, whilst find reports are filed on unidentifyable persons and bodies only.
So the actual problem is to match:
- Identified Persons against Unidentified Persons/Bodies
This turns the “Missing Person” issue around – is a completely different workflow. Now you have to maintain a registry of “found”, but unidentified persons/bodies – while the “Missing Reports” are rather a helpful resource for identification.
Some people say this is discussing half-full vs. half-empty. But I’d say it’s a question of which audience you’re targeting.
